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:
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!
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.
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.)
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:
to be in touch with KC users - future users modules/plugins in the KC collection
to start mentoring/growing/training future maintainers, so you can share the burden down the road
in case you are not doing that already, to see first hand the nitty gritty details of the problems that will haunt you
I have reviewed (rather quickly and not deeply) the PR. Overall it looks good, though I left a recommendation on the versioning being mentioned in the docs. And as I write this, it occurs to me that the version these modules were added to c.g. might be mentioned in the description element of the docs, so that this information is not lost for the users. Not entirely sure about that, but when in doubt, I’d rather have more info than less info.
Hi @russoz, thanks for looking into the PR. I have added PRs #11841 and #11749, and updated version references from community.general in the keycloak collection.
For the redirects can we just add a comment for the pending PR’s to open them to keycloak collection? Let me know how we can handle this.
Happy to announce that Keycloak v3.0.7 is now available on Ansible Galaxy. This release includes all Keycloak modules from the community.general collection. Release 3.0.7 · ansible-middleware/keycloak · GitHub
Please note that bugfix releases must not contain new features (in particular new modules). This should have been a 3.x.0 release.
Looking at the previous releases, this seems to have been done multiple times. I’d suggest to closely look at https://semver.org/, as this is an important requirement for Ansible collections.
Hi,
just wanted to say, that the current release on middleware_automation.keycloak has breaking changes compared to the state of community.general.
As mentioned here: normalize_keycloak_url breaks URLs · Issue #347 · ansible-middleware/keycloak.
There seems to be a diff in the plugins/module_utils/[_]keycloak.py file.
This prevents us from switching switching to middleware_automation.keycloak, yet.
Is this difference intentional or just something that was missed when migrating the changes from cg?
My plan is to redirect new feature PRs to the new repository from now on, and to ask bugfix PRs to be also be created for the new repository first, and only merge them in c.g once the corresponding PR is merged in the new repository.
Then we can soon start deprecating the existing content to replace it with redirects to middleware_automation.keycloak soon, probably for community.general 14.0.0 (the next major release, probably somewhen in October or November).
