Repository navigation
Replies: 2 comments
|
Follow up. We explored the automatic generation a little more and we are starting to achieve some kind of agreement.
automatically converting to Camel Case for the CRD
have runtime specific filters
specifically handled in the generator |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Reference issue for this discussion: #10866
Goal
We want to give people a great experience when configuring Keycloak by using the Keycloak CRD
Nice to have
When adding/changing configuration in the Quarkus distribution, changes are aligned to the CRD.
Current status
The current implementation relies on a "free-form" map of values.
PROS:
CONS:
I went ahead and prepared a list of the current configuration options and how they might look like in a CRD.
Proposals
Here I present two "extreme" alternatives, probably we can evaluate something in-between those.
Automatic CRD generation
In this Draft PR I have explored the possibility of automatically generating the configuration out of the
PropertyMappersin the Quarkus distribution CLI options.Regardless of the technical implementation of it, that remains open, I found a few challenges to achieving the desired UX:
Manual CRD crafting
Manually integrating the configuration options, since they are not "uncountable", is still a viable option at this point in time.
Challenges will be especially in maintenance:
Additional notes
Build time options vs. runtime options, ideally, build-time options should not be available in case a custom(pre-augmented) Keycloak image is provided.
Possibly a validating admission webhook can improve the user experience in this regard.
All reactions