We need to decide how to ship Foreman Ansible modules in https://github.com/theforeman/foreman-ansible-modules to users.
If you would like, more info is available in the discussion at https://github.com/theforeman/foreman-ansible-modules/issues/108
- Leave this repository as is and advertise how to get the modules through use of git and package manager to get the python dependencies
- Turn this into a role and bundle it up into Galaxy
- Move the contents of this repository into Ansible core repository and decommission this git repo
- Treat Ansible core as a snapshot of the modules, and on a regular basis transfer updates to the repository while doing core development here
- Develop modules here and graduate them out to Ansible core
- Package up our modules ourselves. As a user, it’s like installing an “add-on” to ansible providing extra modules.
I will close this poll in 2 weeks time, 5th November, whatever has the most votes we will go ahead with. If we pick the wrong one, we’ll figure that out and can correct course. - @ehelms
We have seen that with the Foreman callback there can be some time between a fix and the actual release.
On a related note: Puppet used to have quite a lot of bundled types. With Puppet 6 they changed this so there are now just a very few that are developed as part of the core repository. The others are developed as standalone but for compatibility reasons are still bundled as a snapshot.
As a developer and a user that makes a lot of sense to me. It allows me to choose exactly which version I use. I don’t know if you can override built in types with Ansible if you need a specific fix. That’s why I voted for Galaxy; it’s a more flexible solution.
This is my concern as well. It sounds like using Galaxy would let us release whenever we needed to release.
I will add one nice thing that comes with being in the Ansible repository is automatic documentation and discovery of the modules. For example, the old module got a page like this:
I would prefer to have it in ansible core but additionally, I like to work on foreman-ansible-module in “our” preferred way / speed. Therefore, I don’t like the to decommission this repo and push a snapshot from time to time from foreman-ansible-module to ansible core.
I think moving stuff to Ansible is the (long-term) way to go. However, I am not sure how quickly this is doable¹ (and then people will still need to install the dependencies themself), so it might be useful to go the packaged “add-on” route in the short term.
@Gwmngilfen why can’t I vote for two things?
¹: I’d love us to only move modules that have a certain “level” of quality, like properly documented, using the nailgun wrapper, having tests [how would we test after we moved?]
By using Ansible, we knew that we’d have to work within their ecosystem eventually. If there are pain points there, our presence in their community will only serve to make it better. I’d really prefer to not try a hybrid approach, as it’s more complicated and more difficult for users to get bleeding edge changes.
IMO the issue of stability/quality of FAM is certainly a concern, but most breakages I’ve encountered are due to Nailgun disliking changing APIs. We have validated Nailgun versions for certain upstream releases (Katello 3.0, 3.4, 3.7, 3.9, etc.). It’s expected that there is some instability on master. The issues surrounding the use of Nailgun in production is definitely something we should address, but I don’t think it should be a blocker in this decision.
As for testing, I believe we can migrate our tests to ansible, though I haven’t really given this much thought or investigated what we need to do.
Could we have the same tooling? In the puppet world you have
puppet-strings to do it yourself. Also sounds like something Ansible Galaxy could automatically do. It doesn’t sound like something specific to us
And hosting? Sure we can add to our growing infrastructure or maybe you can render it as gh-pages and hope that users can find it. My point was more that you get all of that for free which is nice for users and discoverability.
At present, Galaxy is not designed around roles wrapping modules. We can reach out to find out if this is a direction they are going but otherwise we’d be routing around their community prescribed methods.
That was sort of what I was hinting at. It sounds like a valuable thing in the Ansible ecosystem and we shouldn’t stay away from nudging in the right direction.
Multi-vote is an option, take it up with the poll author (not that polls can be changed after creation, it invalidates the existing votes…)
I’ve closed this poll, I think there are pros and cons to a lot of the options, but its seems moving the modules to Ansible core seems to be the most popular choice.
Since @ehelms has some deprecated Foreman & Katello modules already in Ansible, I’d look to him for suggestions no how to migrate FAM into Ansible. Do you know if it would be better to liaise with anyone in the Ansible community or just raise PRs, adding one module at a time? Any insights anyone has would be helpful.
I’m John “gundalow” Barker from Ansible, hope I can answer some of the questions you have.
Starting with Ansible 2.8 (2019Q1) you will be able to use Galaxy to distribute content that isn’t just roles (ie modules, plugins, module_utils)
The future will be more in Galaxy (less in ansible/ansible) though we are just starting that process, lots to be worked out - like how to generate module docs for Galaxy content
Ansible doesn’t backport features. Features only go into
devel and are release in the next
.0 major release
Current stable Ansible releases will get maintenance releases every 3 weeks, so you can distribute bug fixes regularly
Galaxy will allow you to make releases whenever you want. github.com/ansible-network for examples does releases every two weeks.
By defining a number of Foreman maintainers for Ansible we can ensure you can get your PRs to ansible/ansible get merged (via Ansibulbot) once you’ve reviewed it.
If moving into ansible/ansible we’d want to take advantage of the tests you have. We have a Foreman simulator that we use for existing tests
I’m happy to guide you with whichever process you decide, including how to improve coding/documentation and tests.
Thanks for popping in and giving us this information. A few follow up questions that will help guide us:
a) Is there a preview of what distributing modules through Galaxy would look like?
b) With the galaxy change, are there advantages to distributing through Ansible core other than being installed by default with Ansible?
We are currently putting together an example Content collection which will show how roles and modules would look in a GitHub repo and made available via galaxy.ansible.com
Having content distributed with Ansible does make it easier to find, as it’s listed in the main module list.
We should have some example GitHub repos available in the next two weeks