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.
7 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.
4 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.

5 Likes
4

My ideal layout here would be having:

  • a keycloak_client or keycloak_realm or keycloak_api collection (not very good with naming here) containing the modules
  • the existing keycloak collection containing the roles only, and depending on the former.
2 Likes
5

Hi @oranod

My quick answer would be: any transplant from c.g. to a domain-specific collection is welcomed from c.g. perspective - less stuff for us to tend to :smiley: . That being said, I think the major problem is having people to maintain these other collections - along with the technical load, it implies a fair amount of administrative/procedural work and not a lot of people is willing to take on that.

If that part is solved, than the actual transplanting is relatively simple - just follow the steps pointed out by @felixfontein in the proxmox thread.

2 Likes
6

thanks @russoz it’s good to hear this all sounds fine from the steering committee folks / c.g. maintainers.

@guidograzioli has expressed his interest in maintaining the new KC collection and I’m also willing to help out.

I plan to reach out to folks in the community and see if anyone is interested in joining us. will let you know how we get on anyway. cheers.

2 Likes
7

Most certainly, even if it is just so tests runs faster and can actually include keycloak in the mix :smiley: We will submit fixes as we need them independent of whether it is community.general or something else.

2 Likes
8

Hey @guidograzioli and @belaran :waving_hand:

I’d like to revisit this plan to move Keycloak modules that are in the community.general collection into a separate collection.

It shouldn’t be too hard to move all the modules, tests, and docs out of c.general. I can help work on that as well as setting up the collection repo. First, though, I think we need to decide about the GitHub org.

One of the goals is to use the new collection as an upstream for ansible-middleware/keycloak. I’d like to clarify what this should look like. Two options seem to present themselves.

  1. Add a dependency in ansible-middleware/keycloak for the new collection. This would require going through the Hub certification process. I can definitely help with the certification process but it means the ansible-collections GH org might not be the right choice.

  2. Add the new repo as a git subproject here. This should allow us to release ansible-middleware/keycloak without the collection dependency while still using those modules. I guess it probably adds some special test considerations.

1 Like
9

Hello @oranod I’m part for Ansible Middleware project. We had a discussion about this, and We want to go with the second option of yours. Please let us know How do you want to proceed this.

10

Hey @RanabirChakraborty Thanks for getting in touch. Let’s make sure we only have initial discussion in slack. Once we’re all on the same page, let’s move all the communication back here to the forum. Cheers!

11

Hello,
I would like to make more contributions in the future.

What is the official communication channel?

1 Like
12

You can check our project from here (Ansible Middleware · GitHub) and if you want to contact us then the email address is ansible-middleware-core@redhat.com

1 Like
13

Hi @RanabirChakraborty ,

I asked more specific for these modules community.general/plugins/modules/keycloak_authentication.py at main · ansible-collections/community.general · GitHub – which serve managing existing Keycloak instances.

I thought there was IRC channel or something else where we can align

Since i ask here , do you accept contributions for Middleware ?

14

To answer your question, all the middleware related collections/roles will eventually move to Ansible Middleware projects, as the community.general doesn’t have much contributors to take care of it. So Ansible Middleware is the one you are looking for. Currently we are using emails to connect with open source contributors, and we also have a Red Hat slack channel that’s completely internal.
And yes, we would love to have your contribution in any of our middleware collections.

2 Likes
15

@RanabirChakraborty Can i get an invite to the slack channel?

feat(keycloak_realm_key): add full support for all Keycloak key providers by koke1997 · Pull Request #11468 · ansible-collections/community.general · GitHub - This is my PR for the realm keys.

16

Right now the modules are still developed in community.general, and I’m not aware of any timeline of moving them anywhere else. Since there is active development happening (including a PR for a new keycloak_ module), it would be good to know more about when (and how) the move is supposed to happen.

(Also please note that community.general major releases are aligned with ansible-core major releases, so the next one will be in May 2026. Removal of content can only happen with new major releases, and we’ll only do that once a proper release of the new collection with the content is out by then, meaning a non-0.x.y release.)

For communication, I’d suggest to use the forum or Matrix, as these are actually open.

2 Likes
17

As @felixfontein mentioned the modules are still part of the community.general collection. Although from this PR and this PR I can see you’ve figured this out. Thanks for your contributions @koke1997 :tada:

I also wanted to chime in if another contributor finds this discussion somewhat confusing, which is always a consequence of fragmentation. We had a plan to move keycloak modules from c.general to the Red Hat middleware collection. That move “defrags” things a little in the community, hopefully improves quality with things like better testing, and eases some maintainer burden for folks in c.general (following the proxmox example).

I guess things stalled a little during team transition but now @RanabirChakraborty and team are revisiting the opportunity. As mentioned there is an internal slack channel. @hcherukuri has already reached out to me there and I plan to start with a brief introductory call where we can get to know each other and set some context, might also include @gundalow

Of course I 100% agree that discussion should take place in the forum as much as possible. I also think any decision on implementation must take place as an open discussion on the forum. So I hope to help navigate these changes with a community-first approach. I also think it’s great that this discussion is getting revived.

18

Have we decided where the new GitHub repo will be located, ansible-collections or somewhere else? If we can get that setup in the next month or so that should give us time to transition everything and do the deprecation of the modules in community.general.

We’ve done this many times before, we know the steps.

Thanks to everybody that’s helping with this, it shows the strength of the Ansible Community.

19

The hardest part is usually keeping the Git history, since the modules were moved around in the community.general repository (from plugins/modules/identity/keycloak/ to plugins/modules/), and the corresponding unit tests (if there have been some that far back) as well. But that’s basically the only tricky part to consider, and it’s not that tricky either :wink:

1 Like