ansible-middleware/keycloak

RHBK: Major Upgrade fails due to missing `conf/`, `providers/` and `themes/` data from prev. installation

hwo-wd opened this issue · 6 comments

hwo-wd commented

As per 3. of https://access.redhat.com/documentation/en-us/red_hat_build_of_keycloak/24.0/html-single/upgrading_guide/index#install_new_version:

image

we should consider copying conf/, providers/ and themes/ whenever the version changes and copy them over since otherwise the systemd service doesn't come up (assuming one has password blacklists etc. installed).

I haven't experienced issues on any minor update so far, but I think it wouldn't hurt either.
Should we persist the previous version (similar to bootstrapping) as a local fact and then run this task conditionally, wdyt?
Alternatively we could extract the version by stat-ing the installation directory, but the former seems way cleaner to me tbh

guidograzioli commented

Hello; I am actively on this (on the downstream tests for the rhbk collections which are not visible publicly , sorry)

guidograzioli commented

Fact is, ideally there shouldn't be anything in conf/ or providers/ which is not configured by the collection itself; themes is a different beast. I am not sure how to handle the case of "manually" added content.
The upgrade should take care of round-robin restarts, via systemd wait_for facility.

guidograzioli commented

Actually, I don't a reason for not placing the upgrade molecule upstream too

  • 👍1
hwo-wd commented

Fact is, ideally there shouldn't be anything in conf/ or providers/ which is not configured by the collection itself; themes is a different beast. I am not sure how to handle the case of "manually" added content. The upgrade should take care of round-robin restarts, via systemd wait_for facility.

Thinking about it, you are actually right; it's just that the role is missing the possibilities to add policies (black/white lists); moreover, the ability to download providers (the functionality you've recently added via keycloak_quarkus_providers) would have to be extended to support maven downloads (be it from maven central or private maven github repos).
Using the same paradigm we could also tackle themes since at the end of the day they are just jar files deployed similarly to SPIs.
My playbook includes quite a lot of this functionality I could upstream if you're willing to integrate these things into the role? (and you're not worried with over-engineering the role, that is ;-))

guidograzioli commented

Mate, the idea is to catch up feature-wise, and then keep up, with rhbk for the time being :)
Any feature you may be willing to share with the community will be joyfully received (and eventually moved downstream). Just please keep features separated in their PR stream, and hold breaking stuff for major releases

  • 👍1
hwo-wd commented

Closing in favor of #229, #226, #222.

It's only really the /themes directory left:

rhbk-24.0.3# cat themes/README.md
Creating Themes

Themes are used to configure the look and feel of login pages and the account management console.

Custom themes packaged in a JAR file should be deployed to the ${kc.home.dir}/providers directory. After that, run
the build command to install them before starting the server.

You are also able to create your custom themes in this directory, directly. Themes within this directory do not require
the build command to be installed.

But to be honest, from a production point of view the whole thing should be put in providers.