[keycloak-dev] keycloak/extensions-init-container

Stian Thorgersen sthorger at redhat.com
Wed Nov 6 05:42:10 EST 2019


I have a concern with this that it was discussed and merged prior to being
discussed with the wider team.

For the approach in general, I have a few comments:

* Should it be keycloak-init-container rather than
extensions-init-container? I imagine there may be more use-cases for this
in the future (themes, jdbc driver, configuration, etc..).
* I can also see this being used outside of the operator as a regular init
container. Does it support that?
* I don't like it using Python as we use Bash everywhere else in
containers. This adds overhead for maintenance of the container.
* Why python:3-alpine? Is this a supported container in the RH catalogue? I
would imagine it would be safer to go with ubi as the base.

Also, one slightly bigger concern with this approach is installing
extensions from a URL at init time. That can add an overhead to the init
and also a certain level of unpredictability. I imagine cases where one pod
spins up, then someone updates the extension, then another pod spins up. It
seems it would be a manual process to reload pods with the new extension?
Is not a more predictable way to build a container with the extension
directly than to use external URLs?

On Tue, 5 Nov 2019 at 17:03, Bruno Oliveira <bruno at abstractj.org> wrote:

> Good afternoon, just a quick heads up.
>
> A new repository was created on quay.io
> (https://quay.io/repository/keycloak/extensions-init-container) and
> the motivation behind this is to provide support to download and
> install Keycloak extensions inside the Keycloak Operator.
>
> More details in the Jiras below:
> - https://issues.jboss.org/browse/KEYCLOAK-11910
> - https://issues.jboss.org/browse/INTLY-3606
>
> Questions/comments/concerns, please let us know.
>
>
> --
> - abstractj
>


More information about the keycloak-dev mailing list