- systemroles - Fedora mailing-lists

Lab Scenarios
by Cesar Delgado 25 Jan '24

25 Jan '24

Dear Richard: Thank for this wonderful work. Just wondering, is there any prepared lab scenarios to get hands-on experience with this collection. Besides the guided exercises. Using a bunch of VMs, setup a working environment directly from Git definitions. For unattended OS installation, eventually Tinkerbell can do the job... just the OS configuration through this collection. It is about prepare People to deploy environments quickly using a declarative manner (both OS installation and setup). Thank you.

2 1

<> Working Methodology <>
by Cesar Delgado 23 Oct '23

23 Oct '23

Dear All: Thank you so much, for your effort and your great help. Just one question... let's say I would like to use this collection as a template to create my own ansible collection. Following the exact same working methodology. Is there any summary to get a big picture of the whole thing? Because it requires quite a bit of research and compilation to actually understand all the processes followed in this effort. By far, the best approach I was able to find... also good documentation all along the line... just the diagram of the development processes as an entry point to speed up the research and also simplify communication to other programmers. Your faithfully, César *PD: Abstracting what to do, from how to do... is our first step, as suggested in many places on this web site. Definitely, all this documentation is key for us to build something in the long run in Ansible. Thank you so much. *

2 1

Re: CoreOS support
by Richard Megginson 20 Sep '23

20 Sep '23

On Tue, Sep 19, 2023 at 2:19 PM Cesar Delgado < cesar.electronic.engineer(a)gmail.com> wrote: > Thank you for the quick and kind answer. > > Currently there is no way to use Ansible in CoreOs… network setup (nmstate > API), or simply uploading a file (ipxe.iso for rebooting the system from > PXE). > Let me see if I understand you correctly. You want to manage a CoreOS (VM? container?) system using Ansible? What version of Ansible are you using? What is your control node platform? > > It fails due to some python SELinux libraries missing, only shell/cmd > modules work for doing simple tasks. > Then it sounds like this isn't just a system roles issue, but an Ansible issue, if you can't even use builtin modules. We can try to help you, but you might get more help on a general Ansible list/forum. > Very gratefully, Cesar > > > Enviado desde mi iPhone > > El 19 sept 2023, a las 15:52, Richard Megginson <rmeggins(a)redhat.com> > escribió: > > > On Tue, Sep 19, 2023 at 7:50 AM Cesar Delgado < > cesar.electronic.engineer(a)gmail.com> wrote: > >> Dear all: >> Thank you for this great effort. >> Is RedHat CoreOS support in the roadmap? >> > > Can you be more specific? Can you give us some examples of what sort of > CoreOS support you require? > > >> Thank you, Cesar >> >> Enviado desde mi iPhone >> _______________________________________________ >> systemroles mailing list -- systemroles(a)lists.fedorahosted.org >> To unsubscribe send an email to systemroles-leave(a)lists.fedorahosted.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted… >> Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue >> >

2 1

CoreOS support
by Cesar Delgado 19 Sep '23

19 Sep '23

Dear all: Thank you for this great effort. Is RedHat CoreOS support in the roadmap? Thank you, Cesar Enviado desde mi iPhone

2 1

Re: <> Thank you <>
by Richard Megginson 31 Aug '23

31 Aug '23

On Thu, Aug 31, 2023 at 12:24 AM Cesar Delgado <cesar.econocom(a)gmail.com> wrote: > *T*hank you for your quick and kind answer. > *J*ust replicating your demo in home lab as entry point, and play with it > to grasp the core concepts (how to decouple data from logic, how to > properly organize declarations, how static playbooks look like, how to > combine with GitOps patterns and methodology). > ok - the blog series https://www.redhat.com/en/blog/rhel-system-roles has many examples > *A*pparently... OASIS-roles (which is not updated for 2 years now)... has > some parts that are in the future roadmap, but not yet included (such NFS). > Right. Not sure when we will get around to including NFS and other roles in linux-system-roles. > *T*he question would be, which OASIS-roles will have future development > and which will be considered deprecated? I am very interested in > ocp-install, for the moment, I have my own Ansible procedure, but > definitely community based will have much better testing coverage. > I don't know, but ocp-install is outside the scope of linux-system-roles, so unlikely to be included. > *V*ery gratefully indeed, *César* > > > El mié, 30 ago 2023 a las 20:31, Richard Megginson (<rmeggins(a)redhat.com>) > escribió: > >> On Wed, Aug 30, 2023 at 12:29 PM Cesar Delgado <cesar.econocom(a)gmail.com> >> wrote: >> >>> Dear all: >>> Thank you for the effort you are doing here. >>> Is there any training available? >>> I would like to stand up an environment from the demos you provide... >>> but, is there any additional resources to make easy to undertand how to >>> quickly setup things. >>> >> >> Not that I know of. I guess it depends on what exactly you are looking >> for - see https://www.redhat.com/en/blog/introduction-rhel-system-roles >> >> Thank you >>> >>> PD.: By the way, here the Nvidia Ansible role... eventually it could be >>> included to collection: GitHub - NVIDIA/ansible-role-nvidia-driver >>> <https://github.com/NVIDIA/ansible-role-nvidia-driver> >>> >> >> Probably not - it is outside the scope of linux system roles >> >> >>> _______________________________________________ >>> systemroles mailing list -- systemroles(a)lists.fedorahosted.org >>> To unsubscribe send an email to systemroles-leave(a)lists.fedorahosted.org >>> Fedora Code of Conduct: >>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: >>> https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted… >>> Do not reply to spam, report it: >>> https://pagure.io/fedora-infrastructure/new_issue >>> >>

1 0

<> Thank you <>
by Cesar Delgado 30 Aug '23

30 Aug '23

Dear all: Thank you for the effort you are doing here. Is there any training available? I would like to stand up an environment from the demos you provide... but, is there any additional resources to make easy to undertand how to quickly setup things. Thank you PD.: By the way, here the Nvidia Ansible role... eventually it could be included to collection: GitHub - NVIDIA/ansible-role-nvidia-driver <https://github.com/NVIDIA/ansible-role-nvidia-driver>

2 1

Introducing new commit conventions in system roles
by Sergei Petrosian 09 Jun '23

09 Jun '23

Hello team, We introduce commit conventions in our organizations that will help us automate many release tasks - automatically collect commits into changelog, determine semantic version of new releases, and collect commits into release notes. We will follow Conventional Commits <https://www.conventionalcommits.org/en/v1.0.0/> format, it requires you to provide commit type and optional `!` after the commit type to indicate that your commit introduces a breaking API change. You can find more information at Conventional <https://linux-system-roles.github.io/contribute.html#conventional-commits-f…> Commits format <https://linux-system-roles.github.io/contribute.html#conventional-commits-f…> section on our site. It also generally improves commits hygiene in our org. A correct commit format will be verified by a CommitLint GitHub Action, it will verify each commit in the PR to follow conventional commits format, and also the PR title to follow the format for consistency. The action won't be able to verify if we provide a correct commit type and if we indicate a breaking change correctly, so we must pay special attention to it. One concern is with the *Squash and merge *strategy that PRs currently use. When you click the *Squash and merge* button in GitHub UI, it lets you manually modify the resulting commit and push it to main right away. This is a subject to human error because the resulting commit goes straight to main, and in the case of a typo we would need to force push to main to fix it. It is best to move to a *Rebase and merge *strategy instead to ensure that all commits pushed to main have passed CommitLint checks. This is not ideal but the pay off is huge. Let me know if you have any concerns or questions. Thank you -- Sergei Petrosian, RHCE He / Him / His Software Engineer, RHEL System Roles Red Hat Prague, Czech Republic <https://www.redhat.com> spetrosi(a)redhat.com M: +420792444506 IRC: spetrosi <https://www.redhat.com>

1 2

issues with recent ansible-lint and var naming
by Richard Megginson 17 May '23

17 May '23

You might have noticed that the latest ansible-lint is showing issues with variable names: roles/rsyslog/tasks/main_core.yml:358: var-naming[no-role-prefix]: Variables names from within roles should use role_name_ as a prefix. (vars: __file__) roles/rsyslog/tasks/main_core.yml:358: var-naming[no-role-prefix]: Variables names from within roles should use role_name_ as a prefix. (vars: __line__) roles/rsyslog/tasks/main_core.yml:120: var-naming[no-role-prefix]: Variables names from within roles should use role_name_ as a prefix. (vars: __rsyslog_global_common_rule) Or perhaps it is flagging a variable that begins with `ansible_` These are fixed by https://github.com/ansible/ansible-lint/pull/3458 roles/rsyslog/tasks/deploy.yml:13: var-naming[no-role-prefix]: Variables names from within roles should use role_name_ as a prefix. (register: __rsyslog_deploy_templates) roles/rsyslog/tasks/deploy_nolog.yml:17: var-naming[no-role-prefix]: Variables names from within roles should use role_name_ as a prefix. (register: __rsyslog_deploy_nolog_templates) This has been reported as https://github.com/ansible/ansible-lint/issues/3452 Some of the others we will need to fix e.g. var-naming[no-role-prefix]: Variables names from within roles should use role_name_ as a prefix. (vars: tasks) https://github.com/linux-system-roles/logging/blob/main/roles/rsyslog/tasks… In this case, the `tasks` variable should be renamed to `__rsyslog_tasks`

1 0

Updated Jinja/ansible-lint tips
by Richard Megginson 17 Mar '23

17 Mar '23

https://linux-system-roles.github.io/documentation/howto/working-with-ansib… I updated the examples for the latest recommended practices, ansible 2.9, and ansible-lint 6.x. Links are updated as well. I added a section for line wrapping - when ansible-lint complains about line length, what can I do other than "# noqa line-length"? There are lots of recommended ways to do line wrapping.

1 0

Central management of Branch Protection Rules
by Richard Megginson 17 Feb '23

17 Feb '23

The current system roles are a mess of different branch protection rules - many roles have none - and the ones that do have rules are very inconsistent. In addition, it is quite difficult to manage a dozen or so different rules, and a dozen or so status checks, among 2 dozen repos. https://github.com/linux-system-roles/.github/pull/16 remedies that * central management of branch protection rules, with some allowance of per-role changes * consistent, secure rules for all system roles repos This solution uses the github graphql api - https://docs.github.com/en/graphql - which is their next generation api (the current generation api is the REST api). One consequence is that it will be harder (for most roles, anyway) to merge PRs - PR status checks must pass, PRs must be approved by a code owner, admins cannot bypass these checks, et. al. We're currently working on improving the names of the baseos ci status checks - those will be added in the near future - for now we just have the Fedora statuses.

1 0

2025

2024

2023

2022

2021

2020

systemroles