redhat-cop
Discussion: Making infra.leapp Collection RHEL System Role Compliant
Background
We are working on creating a new RHEL system role for RHEL upgrades and have identified two potential approaches. We would like to discuss these with the infra.leapp community to find the best path forward that preserves the existing community while meeting RHEL System Roles requirements (this can also help). We have initially developed a POC of a brand new rhel_upgrade (single) role using state-based approaches, but we are concerned about potentially fragmenting the community around upgrade automation.
Two Approaches Under Consideration
Approach 1: New Standalone RHEL System Role
- Create a completely new
rhel_upgraderole following RHEL System Roles standards. - Implements state-based configuration management
- Pros: Clean implementation, follows all standards from the start
- Cons: Risk of community fragmentation, potential duplication of effort
Approach 2: Make infra.leapp System Role Compliant
- Collaborate with the infra.leapp community to evolve the existing collection
- Adapt infra.leapp to meet RHEL System Roles compliance requirements
- Pros: Preserves existing community, builds on proven codebase, avoids fragmentation. The existing collection already has ansible-lint and ansible-test CI but some of the exceptions they allow will have to be changed
- Cons: Requires coordination and potentially significant refactoring
To be RHEL System Role compliant, the role would need to follow some key standards e.g.:
- Variable naming: all variables prefixed with ROLENAME_ (e.g., leapp_upgrade_target_version)
- Idempotency: Role must be idempotent and support check mode
- Support for all required Ansible versions
- Reboot handling: Must not reboot automatically; set ROLENAME_reboot_needed fact instead
- Use import_tasks over include_tasks where possible
- Figure out a way to handle dependencies - https://github.com/redhat-cop/infra.leapp/blob/main/galaxy.yml#L29 - it looks like infra.leapp uses some modules for rhn/satellite which could be replaced with the rhc system role, and some selinux modules which could be replaced with the selinux system role - if there are any modules which must be used which do not have a replacement, then we can vendor in those modules in the rhel build like we do with rhel system roles
- Add Tests - before doing any refactoring, we must have tests - one strategy would be to take the existing RHEL Upgrades QE tests and create Ansible "wrappers" for them - use Testing Farm and/or github action qemu runners like we do for system roles
- And other changes as specified in the requirements link above, and any changes needed in order to pass strict ansible-lint and ansible-test CI.
Questions for the Community
- Is the infra.leapp community interested in making the collection RHEL System Role compliant?
- What would be the impact on existing users if we refactor infra.leapp to meet these requirements?
Benefits of Collaboration
- Keep upgrade automation efforts consolidated
- RHEL System Role status would increase visibility and adoption
- Better integration with Red Hat's supported automation portfolio
- Compliance requirements often improve code quality and maintainability
Would the community be open to this? We think it could benefit both "infra.leapp" users and the wider RHEL automation ecosystem.
is there any flexibility on any of those rules or are they strictly required? Overall I really like the idea of moving this collection into the system roles. We may need to discuss on some of the points such as why we didn't use system roles to do some of the tasks and why we used modules instead.
is there any flexibility on any of those rules or are they strictly required? Overall I really like the idea of moving this collection into the system roles. We may need to discuss on some of the points such as why we didn't use system roles to do some of the tasks and why we used modules instead.
There is a little flexibility. But to be a Certified Collection it should pass ansible-lint and ansible-test with minimal, justifiable exceptions in .ansible-lint and tests/sanity/ignore-xxx.txt
We also need to decide what it means by "part of RHEL System Roles". Keeping the collection as infra.leapp in Galaxy, RHEL RPM packaging (maybe as part of the existing RHEL leapp-* packages, as perhaps a sub-package), and Automation Hub has a lot of benefits. It isn't clear to be what would be the benefit of having infra.leapp inside of the fedora.linux_system_roles or redhat.rhel_system_roles collection.
@richm, on one of our calls you mentioned that the advantage of including the infra.leapp Ansible roles in RHEL system roles (rhel-system-roles package) over "just" certifying the AAP validated collection is that also small and medium customers who don't have an AAP subscription would be able to use the upgrade RHEL system role in a supported manner from within their Ansible control node. That's how I understood it and it makes sense to me so I'd go that way. Let me know if you meant it differently.
@richm, on one of our calls you mentioned that the advantage of including the infra.leapp Ansible roles in RHEL system roles (
rhel-system-rolespackage) over "just" certifying the AAP validated collection is that also small and medium customers who don't have an AAP subscription would be able to use the upgrade RHEL system role in a supported manner from within their Ansible control node. That's how I understood it and it makes sense to me so I'd go that way. Let me know if you meant it differently.
The infra.leapp collection does not have to be in the rhel-system-roles RPM in order for RHEL customers to use it. There are a couple of alternatives:
- Include the
infra.leappcollection in one of theleappRHEL RPM packages likeleapp. Customers wanting to use theinfra.leappcollection are going to have to installleapp, so it might make sense to bundle them together. - Create a brand new RPM package in RHEL called
ansible-collection-infra-leapp
The latter is the way most Ansible collections are provided in RHEL - it is the convention to name the RPM package ansible-collection-$namespace-$name. The downside is that it is a lot more work to add a package to RHEL, rather than just including the collection in an existing package.
I don't recall we'd discuss the alternatives before. But ok, let's look at them. @richm, you've mentioned that keeping the collection outside of RHEL System Roles yet publishing it in RHEL in different ways has a lot of benefits. What would those be from your point of view?
If I read the https://access.redhat.com/articles/6325611 right, the good thing is that the alternative approaches would still fall under the support scope of ansible-core. I'd need someone from Ansible to confirm that.
Advantages of the alternatives as I see it:
- The RHEL Upgrades team would require no coordination with the RHEL System Roles team for the introduction and further maintanaince of the collection - we'd not consume your time and we'd have more autonomy over the content.
Disadvantages:
- We don't have the Ansible expertise we had hoped you'd bring when integrating the collection into RHEL System Roles to bring best-in-class Ansible content to customers. But perhaps some kind of oversight/guidance from the RHEL System Roles team would be sufficient.
Just for the record, at the moment there are two ansible-collection-* packages in RHEL 8 and 9:
ansible-collection-microsoft-sqlansible-collection-redhat-rhel_mgmt
I don't recall we'd discuss the alternatives before. But ok, let's look at them. @richm, you've mentioned that keeping the collection outside of RHEL System Roles yet publishing it in RHEL in different ways has a lot of benefits. What would those be from your point of view?
If I read the https://access.redhat.com/articles/6325611 right, the good thing is that the alternative approaches would still fall under the support scope of ansible-core. I'd need someone from Ansible to confirm that.
In much of the documentation around RHEL ansible-core usage, "system roles" or "RHEL system roles" is short for "All Ansible content provided by RHEL, including, but not limited to, system roles, ansible-freeipa, ansible-pcp, SAP, Satellite, Insights remediations, ansible-collection-microsoft-sql and ansible-collection-redhat-rhel_mgmt.` I guess because system roles was the first such Ansible content in RHEL.
So yes - IMO, if infra.leapp were to be provided in any RHEL RPM, it would be approved and supported for use by RHEL ansible-core. It does not matter if the infra.leapp is in the rhel-system-roles RHEL RPM package.
There's still the question: If infra.leapp were to be a part of system roles, or RHEL system roles, what exactly does that mean?
Advantages of the alternatives as I see it:
* The RHEL Upgrades team would require no coordination with the RHEL System Roles team for the introduction and further maintanaince of the collection
Maybe eventually, at some point in the future, the RHEL Upgrades team would require no coordination with the RHEL System Roles team for the introduction and further maintanance of the collection. We understand that the leapp team has no experience with Ansible. The system roles team has a lot of experience with helping RHEL sub-system teams to acquire enough experience with Ansible to maintain role code, with on-going help from the system roles team for harder questions.
Then, at some point in the future, the leapp team may not need as much on-going help from the system roles team.
Also note that the infra.leapp collection is supported today by the existing community around this collection, many of whom have a great deal of expertise in Ansible and good practices (because in some cases, they actually wrote and still contribute to https://github.com/redhat-cop/automation-good-practices). So there is already a community of Ansible expertise, even without the system roles team.
-> * -
* - - we'd not consume your time and we'd have more autonomy over the content.
Which to me makes sense - if you fix a bug or add a feature in leapp, you can at the same time change infra.leapp to take advantage of that bug fix/feature, and release leapp and infra.leapp at the same time.
Disadvantages:
* We don't have the Ansible expertise we had hoped you'd bring when integrating the collection into RHEL System Roles to bring best-in-class Ansible content to customers. But perhaps some kind of oversight/guidance from the RHEL System Roles team would be sufficient.
Yes. And oversight from the already existing infra.leapp community who have a great deal of Ansible expertise.
The system roles team would be involved at every stage of the process of making infra.leapp a supported RHEL component.
We will help bring the infra.leapp github repo up to the current standards.
We will help fix issues in the code related to ansible-lint/ansible-test/ansible 2.19/other Ansible good practices issues.
We will help rewrite code to use system roles instead of unsupported modules.
We will help write test playbooks.
We will help with RPM packaging guidance.
Just for the record, at the moment there are two
ansible-collection-*packages in RHEL 8 and 9:* `ansible-collection-microsoft-sql` * `ansible-collection-redhat-rhel_mgmt`
Correct. But as I said, you don't have to go this route - there are advantages and disadvantages, versus including infra.leapp in the leapp RHEL RPM package.
I think we should probably setup a meeting to discuss in more detail with both parties to come to a decision on what path is the best in this scenario.
For the record, we had a call on the delivery method and the outcome is that we'll ship the collection as part of the rhel-system-roles package. The reason to not ship it in a new leapp subpackage is that leapp is not available in RHEL 10.
For the record, we had a call on the delivery method and the outcome is that we'll ship the collection as part of the
rhel-system-rolespackage. The reason to not ship it in a new leapp subpackage is that leapp is not available in RHEL 10.
There's a third option which is a new ansible-collection-redhat-leapp RHEL package. @djdanielsson and @richm have been leading a discussion about this and we're all agreed that is the best way.
@bocekm, I'll tag you on that thread.
I believe making it a separate package and AH collection is The Right Way To Do It. Fedora Ansible collection packaging guidelines - https://docs.fedoraproject.org/en-US/packaging-guidelines/Ansible_collections/ - RHEL follows these guidelines.
We don't need a Fedora package, but we will need a CentOS and RHEL package. We'll handle that internally.