Repository navigation
Replies: 2 comments 5 replies
|
This discussion is a bit odd to me because it is the same thing to say to people that they should explicitly set a configuration option if we can just make things a lot easier and just be smarter about it. I'm mainly in favor of making life easier for people than recommend using bash. I have no clue how to do that on Windows, for instance. What if Arguing that there is confusion is not valid either. I would say you are losing some context from here #10216. And the fact that we have another user asking for it is an indication it is a useful capability. |
I agree if we can provide a uniform and solid experience.
There are alternatives and is an easy task to be performed on any native shell.
I'm not dismissing user's feedback, what I'm saying is that either:
|
Do you really want to force people to create a custom image to use variable substitution? And install additional packages? Not the best UX in my experience. A solid and thought-through experience is something that works in the same way regardless of the shell.
The capability was originally thought for import realm at start-up and too help people doing gitops. This is what people usually use to provision realms and do some automation. Use the That said, for me it is matter of fixing docs for now and state that it should work only when importing at start-up.
It is a useful capability and instead of dropping we should improve it. I think that is the point we disagree. W.r.t. Vault, that is another story as we have many other gaps in this area, mainly after the removal of the Elytron Credential Store, such as fetch credentials for the database. I don't know what else you mean by |
|
TLDR: I would like to add that I found it always artificial that keycloak can do those tricks. Sure it seems convenient in the first place. But I agree with @andreaTP that if keycloak supports something like this here, why not everywhere. How many templating and configuration tooling is keycloak going to replicate in favour of usability.
All GitOps systems I saw so far create static "complete" configuration and sync and apply it as is. The operator may has secrets, which he knows how to add to the mix but that's mostly it. A GitOps workflow which creates a template (used at runtime) which is than mixed dynamically with pipeline variables which have to be hand over to keycloak (at runtime) to create a temporary realm config seems a bit odd to me. Additionally from operations perspective the interface is opaque. Which version of the template am I using. did it change in keycloak? Did keycloak changed substitution rules? I would expect such use case not in GitOps but more in legacy pipeline or scripted setups. |
|
Our vault is a form of templating and it requires a bit more configuration. And our vault is very, very limited on what you can do. The capability herein being discussed should be seen as a different way of fetching values when provisioning realms at startup. With a focus on running the server as a container. It should not be added to import/export (for provisioning they are more complicated as you need a separate job) commands at all but specific to provisioning at startup. If that was a mistake and we ended up with an agreement that we should not do it, let's not do it and sorry for the noise :) Lesson learned. I also see your "complete" configuration use case, but I also see others doing differently and relying on placeholders with environment-dependent values. |
|
I fully agree that this feature has some appeal. Also Its not on me to push in one or the other direction I just left my 2 cents as I have a more cloud native use case and can't relate to much with the "realm on init" workflow anymore. |
Uh oh!
There was an error while loading. Please reload this page.
Currently, the
kc.sh importcommand does an environment variables substitution in the json file provided.The implementation followed up on this issue: #10216
There are additional considerations:
exportbashThe proposal here is to drop this feature in the next major release as:
envsubst <TEMPLATE_FILE >OUTPUT_FILEAll reactions