You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some of the variables of values file are written in upper camel-case. The specification asks for lower camel-case.
It can be a little thing (even implying a major release, following semver versioning), but marks a really big difference for the deployment experience, when deploying multiple helm charts.
Indeed, a lot of projets follow the same naming convention, and we can find similar architecture in helm templates. Moreover, as Zitadel uses upper camel-case for application's variables, this will help to mark the difference between the deployment-related values, and the application-related values.
Another idea could be to inherit from @bitnami pattern, a reputed organisation that produces stables charts which uses a global variable expansion to handle multiple deployments similarly.
All those little points also may add value for a potential CNCF incubation, as it could help empowering the project adoption.
Describe your ideal solution
As an Ops, I want to have a homogenous infra-as-code flow to handle several deployments the same way, reducing cognitive complexity.
Version
No response
App version
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered:
Preflight Checklist
Describe your problem
Some of the variables of values file are written in upper camel-case. The specification asks for lower camel-case.
It can be a little thing (even implying a major release, following semver versioning), but marks a really big difference for the deployment experience, when deploying multiple helm charts.
Indeed, a lot of projets follow the same naming convention, and we can find similar architecture in helm templates. Moreover, as Zitadel uses upper camel-case for application's variables, this will help to mark the difference between the deployment-related values, and the application-related values.
Another idea could be to inherit from @bitnami pattern, a reputed organisation that produces stables charts which uses a global variable expansion to handle multiple deployments similarly.
All those little points also may add value for a potential CNCF incubation, as it could help empowering the project adoption.
Describe your ideal solution
As an Ops, I want to have a homogenous infra-as-code flow to handle several deployments the same way, reducing cognitive complexity.
Version
No response
App version
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered: