community.general
community.general copied to clipboard
ansible-collections
FreeIPA modules are incomplete
Summary
I am trying to automatically add hosts to our IPA but when using the ansible module community.general.ipa_host no kerberos principal is generated for the host. In contrast, when using the web fronted of IPA the principal is automatically generated. Therefore I looked into the IPA's API documentation and realized a lot of useful functionality is missing in the ansible collection.
I will hopefully soonish follow up with a merge request regarding this issue.
Meanwhile I wanted to ask the community on how we should move on in implementing. Do we just want community.general to be a wrapper for the IPA API or do we want do mimic the behavior of IPA's web UI - meaning the ipa_host module should also create a principal name for the host?
Issue Type
Feature Idea
Component Name
ipa
Additional Information
Code of Conduct
- [X] I agree to follow the Ansible Code of Conduct
Files identified in the description:
If these files are incorrect, please update the component name section of the description or use the !component bot command.
Since the module is already largely a IPA admin API wrapper, I think it is probably best to continue that. I realize the GUI behavior is relatively stable, but I am not aware of 'GUI guarantees' on functionality so it is likely better to decouple this module from the GUI behavior and just document well what is needed to do some typical operations. I also don't think we need to strictly be a API wrapper, but largely that is what has happened and from a backwards compatibility perspective, that seems like something with a lot of inertia that needs a really good reason to change. I realize that is not perfectly 'ansible-like' and that ideally modules should focus on states rather than API execution. What we have is pretty good, but as you observed it trends more to the API conformance.
Short of points of others may make that I have missed, I would vote to trend closer to the API wrapper functionality short of a substantial refactor of all the modules (and even then, not sure what to do on the backwards compatibility).
You might also be interested in the 'official' FreeIPA collection: https://galaxy.ansible.com/freeipa/ansible_freeipa
@felixfontein the FreeIPA collection seems to be quite complete and up-to-date. IMHO we should deprecate the IPA support in here - long period of course. What do you think?
I don't know that collection well enough to be able to comment on that. Maybe start a discussion on the forum on this? Also it would be nice to inform the contributors to our FreeIPA modules about this disucssion.
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. After all, isn't that what this module is for?
Here's the discussion on the forum: https://forum.ansible.com/t/43501
Pinging @0b11stan @abakanovskii @aBUDmdBQ @cwchristerw @h3po @irozet12 @jansobczak @jwbernin @parsa97 @risadams @sedrubal @SJay3 @yhal003 who contributed to these modules in the last years.
but I see no reason to shut down a module that is working for people and filling functionality that was contributed by the community.
There is one reason: this module (and the other FreeIPA ones in this collection) is eating up maintainer resources (there are PRs/issues for it from time to time; and then there is general collection work that also has to touch this module / the associated module_utils), and also things like disk resources on everyone who installs community.general (there are a lot of folks who install it, and most folks only use a small fraction of its contents). While these resources aren't that high, they are not zero.
Whether these costs are high enough to warrant removing these modules, that's of course a completely different question.
(It would be great to have this discussion on the forum, btw, and not here. The forum's there for discussions, as opposed to issues on GitHub :) )
I will also duplicate this on the forums in addition to here.
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.
