Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow traits to be configured via configmap/secrets #3891

Closed
agiertli opened this issue Dec 12, 2022 · 2 comments
Closed

Allow traits to be configured via configmap/secrets #3891

agiertli opened this issue Dec 12, 2022 · 2 comments
Assignees
Labels
area/traits kind/feature New feature or request

Comments

@agiertli
Copy link

agiertli commented Dec 12, 2022

Right now the trait configuration values are hardcoded in the Integration or KLB itself.

It would be useful to have a possibility to externalize that configuration. Example CLI command could look like:
-t container.cpu={{configmap:mycm/cpu}}

This is especially important in context of "kamel promote" feature, because if you can't externalise config, then you are forced to re-use the same trait configuration values across environment. Good example is container trait - where you typically have different values for mem/cpu/replicas across dev and prod.

@squakez squakez added kind/feature New feature or request area/traits labels Dec 12, 2022
@squakez
Copy link
Contributor

squakez commented Dec 12, 2022

It could be that one, or maybe also any properties available in application.properties, being the properties also configurable from a Configmap or a Secret.

@squakez squakez self-assigned this Feb 8, 2023
This was referenced Feb 8, 2023
@squakez
Copy link
Contributor

squakez commented Feb 10, 2023

With the presence of the dry-run provided in #4050 it should makes sense to post process any profile with Kustomization style approach. Ideally with the new feature, you will kamel promote ... -o yaml that would produce an Integration CR on top of which we can apply any customization via kubectl apply -k. I am closing this in favour of the aforementioned approach.

@squakez squakez closed this as completed Feb 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/traits kind/feature New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants