You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by "squakez (via GitHub)" <gi...@apache.org> on 2023/02/08 15:35:04 UTC

[GitHub] [camel-k] squakez opened a new pull request, #4038: feat(trait): dynamic configuration

squakez opened a new pull request, #4038:
URL: https://github.com/apache/camel-k/pull/4038

   <!-- Description -->
   With this PR we enable the configuration of traits via Kubernetes Configmap. We can only provide this feature when defining the traits as annotation. I've tried to enable it for the generic use case but since we have a static type defined for each trait (ie, bool or int properties) the serialization to Integration and Trait type fail as we need to declare the configmap key to use, which is a string. We may revisit this in the future to make the Trait type flexible enough not to be forced to use its type, but in the while I think it's a good start.
   
   Closes #3891 
   
   <!--
   Enter your extended release note in the below block. If the PR requires
   additional action from users switching to the new release, include the string
   "action required". If no release note is required, write "NONE". 
   
   You can (optionally) mark this PR with labels "kind/bug" or "kind/feature" to make sure
   the text is added to the right section of the release notes. 
   -->
   
   **Release Note**
   ```release-note
   feat(trait): dynamic configuration
   ```
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [camel-k] lburgazzoli commented on pull request #4038: feat(trait): dynamic configuration

Posted by "lburgazzoli (via GitHub)" <gi...@apache.org>.
lburgazzoli commented on PR #4038:
URL: https://github.com/apache/camel-k/pull/4038#issuecomment-1424150738

   I'm not very sure that what you are describing here is the right way of using kustomize, what one would expect is to write something like:
   
   ```yaml
   resources:
     - integration.yaml
   
   patchesJson6902:
     - target:
         group: camel.apache.org
         version: v1
         kind: Integration
         name: test
       patch: |-
         - op: replace
           path: /traits/container/port
           value: 6789
   ```
   
   So I would expect `kamel promote` to have an option to generate a yaml file you can then post-process with kustomize. 
   
   The main point for me is that kustomize is pretty much the standard for post processing resources as it is embedded in kubectl (i.e. kubectl applu -k) and integrated by almost all the CD tools (ArgoCD, Flux, etc) so any other option would make things a little special. 
   
   Btw, those are my 2c :) I think it would be perfectly possible to have both the solution in place, but for the specific case of the #3891 a standard way would be to leverage kustomize.
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [camel-k] squakez commented on pull request #4038: feat(trait): dynamic configuration

Posted by "squakez (via GitHub)" <gi...@apache.org>.
squakez commented on PR #4038:
URL: https://github.com/apache/camel-k/pull/4038#issuecomment-1422861951

   > usually this kind of customisations are handled using either an helm chart or using kustomize (i.e. you don't see this approach for configuring the cpu/memory for deployment), is there any reason not to use kustomize ?
   
   No, I haven't thought about it. I'll have a look to see how does it fit, thanks!


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [camel-k] squakez commented on pull request #4038: feat(trait): dynamic configuration

Posted by "squakez (via GitHub)" <gi...@apache.org>.
squakez commented on PR #4038:
URL: https://github.com/apache/camel-k/pull/4038#issuecomment-1424323186

   Thanks @lburgazzoli I agree and prefer the declarative approach, also because, the imperative one cannot work with traditional traits the way they are (we can only make it work in annotations). While it's clear how we can kustomize via `kubectl -k`, what I miss to understand is the following statement
   > So I would expect kamel promote to have an option to generate a yaml file you can then post-process with kustomize
   
   When we promote, we copy an Integration CR and we create a cloned one via k8s API. We can let the user provide a kustomization config file, like the one you suggested, but I am not able to understand if there is any API to _apply_ in a similar fashion how we'd `kubectl apply -k`. Do you mind elaborating a bit more this part? Thanks!


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [camel-k] squakez closed pull request #4038: feat(trait): dynamic configuration

Posted by "squakez (via GitHub)" <gi...@apache.org>.
squakez closed pull request #4038: feat(trait): dynamic configuration
URL: https://github.com/apache/camel-k/pull/4038


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [camel-k] lburgazzoli commented on pull request #4038: feat(trait): dynamic configuration

Posted by "lburgazzoli (via GitHub)" <gi...@apache.org>.
lburgazzoli commented on PR #4038:
URL: https://github.com/apache/camel-k/pull/4038#issuecomment-1422845886

   usually this kind of customisations are handled using either an helm chart or using kustomize (i.e. you don't see this approach for configuring the cpu/memory for deployment), is there any reason not to use kustomize ? 
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [camel-k] squakez commented on pull request #4038: feat(trait): dynamic configuration

Posted by "squakez (via GitHub)" <gi...@apache.org>.
squakez commented on PR #4038:
URL: https://github.com/apache/camel-k/pull/4038#issuecomment-1424125601

   Having a look at Kustomize, I guess we can try to apply the same principles. So, for instance, we could have an Integration like the below:
   ```
   apiVersion: camel.apache.org/v1
   kind: Integration
   metadata:
     name: test
   spec:
     ...
     traits:
       container:
         port: 1234
   ```
   and a Kustomize like configuration (ie, `prod-traits.yaml`) as below:
   ```
   apiVersion: camel.apache.org/v1
   kind: Integration
   metadata:
     name: test
   spec:
     traits:
       container:
         port: 6789
   ```
   We can think of `kamel run ... --kustomize xyz.yaml` and `kamel promote ... --kustomize xyz.yaml` that would take care to merge the content of the second into the first one. I was having a look at the Kustomize dependency API and I wonder if it makes sense to us it at all. I think we can simply have the same result by applying a merge on our own before pushing the resource to the cluster (it could work both when running the first time or promoting where the operator create a copy of the source integration).
   
   @lburgazzoli wdyt?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [camel-k] squakez commented on pull request #4038: feat(trait): dynamic configuration

Posted by "squakez (via GitHub)" <gi...@apache.org>.
squakez commented on PR #4038:
URL: https://github.com/apache/camel-k/pull/4038#issuecomment-1426020595

   Superseded by #4050 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org