Keycloak modules in community.general

Project Discussions
, ,
1

Hello!

A couple of weeks ago I barged into a pull request in the community.general collection that was updating some Keycloak modules.

Something that stuck out to me was a comment that @russoz made to the effect that the changes looked good but he didn’t have the domain-specific knowledge to assess the logic.

It seems, to me, that c.general suffers from two problems. The first is that modules are included in collections where there is no clear high-level use case. The second is a risk that the quality of the content might not be as robust due to the lack of specific expertise with the technology.

Initially I floated the idea of incorporating the keycloak_* modules from c.general into ansible-middleware/keycloak. @felixfontein pointed out that there was a hard fork of some of the community modules a while back, which was initially pretty discouraging.

I got in touch with @belaran and @guidograzioli from the Red Hat Ansible middleware team.

Guido explained that the reason for the hard forking was that there is a downstream version of the ansible-middleware/keycloak collection that Red Hat supports. Due to this, that collection cannot have dependencies on c.general because it does not offer support on Automation Hub. You can find a bit more detail in this discussion thread.

Guido also explained that the forked modules are the ones required for the keycloak_realm role only. They didn’t fork all the Keycloak modules from c.general.

After a bit more discussion, Guido mentioned that he’d like to see the keycloak_ modules get extracted from c.general into their own collection.

Not only that but Guido offered to contribute to the new collection and be a maintainer! This could also result in that new Keycloak collection having a downstream offering on Automation Hub, which would allow the ansible-middleware/keycloak collection to depend on it again.

To move forward with this, I’d like to initiate a discussion with current maintainers, @felixfontein , @russoz , and fgruenbauer (who I guess has not joined the forum so maybe we can open a corresponding issue in the repo).

I also have questions:

  • Does it sound like a reasonable idea to extract the keycloak_ modules from c.general into their own collection?
  • Are we overlooking reasons to keep the modules in c.general?
  • If we did extract modules into their own collection, what does the process would look like? Should we extract the modules into a new collection and then deprecate them in c.general? After the deprecation period, folks would need to install the new collection to use the modules.
3 Likes
2

Regarding the process: I wrote that down for community.proxmox here: What's up with proxmox.community? - #2 by felixfontein For a Keycloak collection it would be the same, up to updating the names in that process :wink:

If there is one or more maintainer who wants to maintain that collection, that’s perfect! From c.g’s point of view, there’s no reason to not move the modules. The main reasons to not move content out of community.general in the past have been:

  1. There haven’t been maintainers for collections for a set of modules/plugins. (That’s still the main reason why it is not happening more often.)
  2. We had a rule that content from collections included in Ansible can only be moved to collections that are also part of Ansible. That prevented some moves, but we removed that rule anyway. So this is no longer preventing anything.
2 Likes
3

FYI, I pinged everyone who contributed to Keycloak modules (I hope I didn’t miss anyone) in ~the last year and pointed them to this discussion.

1 Like