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&gt; wrote: