The community.general collection currently hosts 19 modules related to FreeIPA or IPA. There 25 open issues related to those modules, some dating back from 2021. Whilst these modules have had some code changes, some as recent as February this year, most of the PRs for the last 12 months were about documentation updates.
However, there is another collection, freeipa.ansible_freeipa (github, galaxy) that seems to be way more up-to-date and actively maintained. To be fair, they have open issues pre-dating the ones in c.g., but they have surpassed the issues reported in c.g. in many different levels.
Out of the 19 modules found in c.g., I found a direct corresponding module in the ansible-freeipa collection for all but 4 of those modules, namely: ipa_getkeytab, ipa_otpconfig, ipa_otptoken, and ipa_subca.
I donât think it make sense to split our efforts in these two different fronts for the same product/service, so I would like to feel the temperature in the community about deprecating the modules in c.g. (with a very long deprecation period, not to disrupt anyoneâs playbooks), and focus the IPA effort in the dedicated collection.
The product I currently support makes heavy use of the IPA modules, and the effort to migrate to one of the other Ansible galaxy modules, while not impossible, would be a huge burden.
If there is enough effort to warrant this as deprecated, I would kindly request that the deprecation window be extended long enough (at least 24 months) for us to schedule a migration as well as support existing fielded deployments.
However, the collection is well-maintained by the FreeIPA devs and from what Iâve seen so far, it all works and stays up to date with the FreeIPA / RH IdM features
Only the collections that are part of the Ansible Community Package show up there. And since freeipa.ansible_freeipa isnâtâŠ
Do you really need the documentation in this place? Or do you just want to have an online documentation of this collection? If this is the case, the documentation on galaxy.ansible.com might be what youâre looking for.
Fair enough, that makes sense, I didnât know it wasnât a part of the community package (we mostly use ansible-core with a requirements.yml). However, I do use https://docs.ansible.com a lot when looking up docs, and indirectly through https://zealdocs.org, because they index all those docs and wrap it in an offline package. This allows me to âjustâ look for module names by remembering partial names or browsing to find something that might match.
Well, both, the online docs on Galaxy are not as searchable as the ones on docs.ansible.com are. E.g. looking up a module on Galaxy requires you know in which collection it is, while searching for âvmware groupâ on docs provides modules as well as guides to set it up from both the community.vmware as vmware.vmware
But also, AWX (AAP), TheForeman (Satellite) and a whole bunch of other Red Hat assets do have their docs in the same place. This seems like a weird outlier.
Well, my suggestion is not to move, but to simply deprecate - the other collection already exists. And as mentioned in the original text, with a very long deprecation period.
Hi @risadams the regular deprecation period in c.g. is two major versions, roughly one year. For cases where we qere concerned it would be more disruptive, we have used four major versions, which gives the two years you suggested.
I would be suggesting something like that for this case so we seem to be aligned.
Maybe thereâs just some misunderstanding on my side. I interpreted âmove content out of c.gâ not only as actively moving content to another collection, but also deprecating stuff in favor of content in another collection that already exists. And therefor I though we should follow those rules in this case.
I might be wrong there, English isnât my first language.
In any case, just to be clear: what I am proposing is NOT moving content from one place to another[1], but rather to deprecate the existing modules in community.general so that we do not have a duplication of effort.
Honestly, I havenât done a comparison in a long while. I can tell you I first landed here because that module was not complete. Itâs been a while, but I donât think it supported setting a otp as an authtype. For what itâs worth, neither did this module at the time (or at least not in a way that worked), but a simple PR fixed that. Iâd be OK with advertising limited future development, or even encouraging people to use the FreeIPA collection, but I see no reason to shut down a module that is working for people and filling functionality that was contributed by the community.
I donât think it make sense to split our efforts in these two different fronts for the same product/service
Honestly, I highly doubt it is being split in any traditional sense. I donât believe there are common contributors. There may be reasons for marking deprecation, but this one doesnât convince me much.
I would generally be in agreement with a long deprecation time as long as the other module set meets or exceeds all the functionality in this one (I think the two years is sufficient). I am split as to if we should ever truly just delete the module, as advertising its status should be sufficient so people can make an informed decision about its use, but also not cutting the legs out from people whose use of the module works just fine.
As to my earlier example, both modules had items dealing with ipausers, but the other did not support otp as authtypes. If during conversion, the community finds functionality which is not available in the other module, I think the deprecation should be suspended, and then restarted only when the other module publishes versions such that the community wouldnât be losing functionality with the deprecation.
I think that its possible that I found that I wouldnât be able to remotely connect to FreeIPA with IP address or domain when using freeipa.ansible_freeipa collection, because Iâm using Docker to run FreeIPA. Iâm currently using ipa_host, ipa_user and ipa_pass in every FreeIPA module I use from community.general.
Has anyone ever been in contact with the maintainers of freeipa.ansible_freeipa? (Are they maybe even on this forum?) Would be interesting to see what they think about this (maybe they have some interest to quickly add missing functionality to their collection that is present in community.general, or even migrate some of the modules?)âŠ
How are you? I see you are the maintainer and top-contributor of the freeipa.ansible_freeipa collection, and I would like to invite you to this conversation. Also, I would like to extend the same invitation to @rjeffman, the second top contributor in that collection.
The freeipa.ansible_freeipa collecion is clearly more actively maintained than the ipa_* modules in communtiy.general, and I am trying to argue for deprecating the c.g. modules in favour of the ansible_freeipa ones. However, as you can notice from the comments above, there might be some gaps.
So, I guess the first question is: what do you guys think of this idea? And if you like it, do you think there is anything you can do on your side to smoothen the transition for the users? Thanks in advance.
The community.general IPA modules use a different communication approach than ansible-freeipa to connect to the IPA servers that will never be implemented in ansible-freeipa. If someone depends on that kind of connection (through json-rpc and http(s)) their use-case would not be covered by ansible-freeipa.
There are also requirements on support for ansible-freeipa that may impose some difference on expected features and what can and will be delivered by ansible-freeipa.
I donât have an opinion on the deprecation of the community.general IPA modules, and will be happy to help people wanting to migrate, to the âcurrentâ version of ansible-freeipa, but implementing compatibility with missing features may not be on the short term roadmap due to several factors, even if it would something weâd like to do.
Thanks for chipping in! I think that kinda settles the issue - the two sets of modules are not directly interchangeable, not without other operational adjustments at least, assuming that none of these communications methods are being deprecated by FreeIPA in the near future.
So if I got it right the c.g. modules rely on JSON-RPC over HTTP and ansible-freeipa use some thing else - what would that something else be? The next step here is to add docs instructing users how to choose between one or the other, and having those details will certainly help.
I donât think that any communication method will be deprecated in the foreseeable future.
FYI, ansible-freeipa uses the IPA Python API and thatâs why it requires the managed node to be a member of the IPA realm (either a server or a client). There are several advantages for this method, but you also need shell access to the managed node, be it a machine (metal or virtual, through ssh) or a container (through container connectors).
