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(a)abstractj.org> wrote:
Good afternoon, just a quick heads up.
A new repository was created on quay.io
the motivation behind this is to provide support to download and
install Keycloak extensions inside the Keycloak Operator.
More details in the Jiras below:
Questions/comments/concerns, please let us know.