Keycloak modules in community.general

Project Discussions
, , ,
21

Hello,

We currently have 31 Keycloak-related modules in community.general. The keycloak collection already includes four modules keycloak_client, keycloak_realm, keycloak_role, and keycloak_user_federation.

My proposal is to migrate the remaining modules incrementally, moving them one by one and adding the relevant Molecule tests for each module as part of the process. To keep things organized, I’ve grouped them by functional area:

Group Modules

Group Modules
Directory & Access keycloak_user, keycloak_group, keycloak_identity_provider, keycloak_user_rolemapping, keycloak_realm_rolemapping, keycloak_user_execute_actions_email, keycloak_userprofile
Client Extras keycloak_clientscope, keycloak_clientscope_type, keycloak_clientsecret_info, keycloak_clientsecret_regenerate, keycloak_clienttemplate, keycloak_client_rolemapping, keycloak_client_rolescope
Realm Metadata & Keys keycloak_realm_info, keycloak_realm_keys_metadata_info, keycloak_realm_key, keycloak_realm_localization
Components keycloak_component, keycloak_component_info
Authentication keycloak_authentication_required_actions, keycloak_authentication, keycloak_authentication_v2
Authorization keycloak_authz_authorization_scope, keycloak_authz_permission, keycloak_authz_permission_info, keycloak_authz_custom_policy

The plan would be to submit PRs to the keycloak collection, and once merged, redirect users to consume these modules directly from the collection. I’d like to hear your thoughts!

Thanks,
Harsha

1 Like
22

Hi @hcherukuri ,

I am happy that there is a plan, based on the actual artefacts. However, I am concerned about this “one-by-one” approach and how long it will take. I reckon it could, likely, produce a situation where users will need to install both collections to use a module from CG and another from the KC collection.

The redirections help to mitigate the issue, but nonetheless, my personal preference would be to migrate to the new collection straight away.

Just my $0.02

PS: As a disclaimer, I am not an user of these modules, so take my opinion with a sizable grain of salt.

2 Likes
23

I agree with @russoz, it would be a lot easier for us and users if the migration would happen in one go. On the other hand, assuming the migration will take < 6 months, this won’t be a problem anyway since there won’t be another major c.g release between in < 4 weeks (it’s unlikely that until then we will remove anything) and in ~6 months. So from user’s point of view, nothing will be removed. (We could also just keep the modules around and only deprecate them, and only do the removal right before the major release in winter. That way it’s easier to add bugfixes, which we’d require to first go into the new location until they are backported, and once the new collection has a release with a module included we can deprecate a module.)

Also note that contributors are still actively working on existing and new keycloak modules (Pull requests · ansible-collections/community.general · GitHub).

1 Like
24

Thanks for the feedback. I will work moving then all at once. Once I have it ready will reach you out for review.

3 Likes
25

Hi @hcherukuri

One other thing, still around this topic: we have a number of issues, and more important, active pull requests, including for the inclusion of new modules, all related to Keycloak.

I would suggest you tag along those existing issues and PRs, for a number of reasons:

  1. to be in touch with KC users - future users modules/plugins in the KC collection
  2. to start mentoring/growing/training future maintainers, so you can share the burden down the road
  3. in case you are not doing that already, to see first hand the nitty gritty details of the problems that will haunt you :slight_smile:

WDYT?