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 agree if we can provide a uniform and solid experience.

I have no clue how to do that on Windows ... is not installed into the container image? What do I need to do to make it work with zsh?

There are alternatives and is an easy task to be performed on any native shell.

Arguing that there is confusion is not valid either.

I'm not dismissing user's feedback, what I'm saying is that either:

• we provide a solid and thought-through UX (aligned with Vault etc. etc.)
• we drop a non-critical feature that can be arguably easily substituted with OS native tools

There are alternatives and is an easy task to be performed on any native shell.

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.

we provide a solid and thought-through UX (aligned with Vault etc. etc.)

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 import command is not really gitops friendly and it complicates provisioning if running in a container. You need to run this command prior to start the server instead of doing just starting the server. These approaches to import/export are targeted for different use cases.

That said, for me it is matter of fixing docs for now and state that it should work only when importing at start-up.

we drop a non-critical feature that can be arguably easily substituted with OS native tools

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 etc, etc.

TLDR:
I would not expect templating in keycloaks domain but rather use operations tools and instead provide examples how to solve this with external tooling, (helm, envsubst, etc)

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.

Use the import command is not really gitops friendly and it complicates provisioning if running in a container. You need to run this command prior to start the server instead of doing just starting the server. These approaches to import/export are targeted for different use cases.

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.