You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by GitBox <gi...@apache.org> on 2021/02/04 17:43:49 UTC

[GitHub] [camel-k] lburgazzoli opened a new issue #2003: Revisit configuration oprtions

lburgazzoli opened a new issue #2003:
URL: https://github.com/apache/camel-k/issues/2003


   As today there is a little bit of confusion about the options to configure the runtime (you can blame me as I introduced them in the early days of camel-k) and I think it is now time to rethink them.
   
   I'm thinking about something like:
   
   ```
   --build-property  key=val 
   --config-property key=val[@build]
   --config          configmap|secret|file:name[/key]
   --resource        configmap|secret|file:name[/key][@path]
   ```
   
   
   This issue also relates to:
   - https://github.com/apache/camel-k/issues/1831
   - https://github.com/apache/camel-k/issues/1680


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

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



[GitHub] [camel-k] astefanutti commented on issue #2003: Revisit configuration options

Posted by GitBox <gi...@apache.org>.
astefanutti commented on issue #2003:
URL: https://github.com/apache/camel-k/issues/2003#issuecomment-843970447


   That sound like a good idea worth exploring. If we follow that path, we may want to deprecate the `.spec.configuration` field from the Integration API/CRD.


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

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



[GitHub] [camel-k] lburgazzoli commented on issue #2003: Revisit configuration oprtions

Posted by GitBox <gi...@apache.org>.
lburgazzoli commented on issue #2003:
URL: https://github.com/apache/camel-k/issues/2003#issuecomment-773487880


   /cc @astefanutti @squakez 


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

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



[GitHub] [camel-k] lburgazzoli edited a comment on issue #2003: Revisit configuration options

Posted by GitBox <gi...@apache.org>.
lburgazzoli edited a comment on issue #2003:
URL: https://github.com/apache/camel-k/issues/2003#issuecomment-843874243


   @squakez @nicolaferraro @astefanutti 
   
   wondering if we should create a `configuration` trait at this point so when we will implement https://github.com/apache/camel-k/issues/2165, we could also use the same mechanic to attach configuration properties to bindings, kamelets & what not


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

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



[GitHub] [camel-k] lburgazzoli commented on issue #2003: Revisit configuration options

Posted by GitBox <gi...@apache.org>.
lburgazzoli commented on issue #2003:
URL: https://github.com/apache/camel-k/issues/2003#issuecomment-843874243


   @squakez @nicolaferraro @astefanutti 
   
   wondering if we should create a `configuration` trait at this point so when we will implement https://github.com/apache/camel-k/issues/2165, we could also use the same mechanic to attach configuration properties to bindings, kamelets & what noy


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

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



[GitHub] [camel-k] lburgazzoli commented on issue #2003: Revisit configuration oprtions

Posted by GitBox <gi...@apache.org>.
lburgazzoli commented on issue #2003:
URL: https://github.com/apache/camel-k/issues/2003#issuecomment-773487880


   /cc @astefanutti @squakez 


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

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



[GitHub] [camel-k] astefanutti edited a comment on issue #2003: Revisit configuration options

Posted by GitBox <gi...@apache.org>.
astefanutti edited a comment on issue #2003:
URL: https://github.com/apache/camel-k/issues/2003#issuecomment-843983721


   Also, in that spirit of moving / "encapsulating" the configurability responsibility to the traits, it may be logical to:
   * Move the `spec.repositories` field (Maven repositories) into the _builder_ trait
   * Move the `spec.serviceAccountName` field into the _pod_ trait


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

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



[GitHub] [camel-k] astefanutti commented on issue #2003: Revisit configuration options

Posted by GitBox <gi...@apache.org>.
astefanutti commented on issue #2003:
URL: https://github.com/apache/camel-k/issues/2003#issuecomment-843983721


   Also, in that spirit of moving the configurability responsibility to the traits, it may be logical to:
   * Move the `spec.repositories` field (Maven repositories) into the _builder_ trait
   * Move the `spec.serviceAccountName` field into the _pod_ trait


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

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



[GitHub] [camel-k] heiko-braun commented on issue #2003: Revisit configuration options

Posted by GitBox <gi...@apache.org>.
heiko-braun commented on issue #2003:
URL: https://github.com/apache/camel-k/issues/2003#issuecomment-833346914


   Would a `configmap` resource contain `build-properties` and `config-properties` itself? 


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

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



[GitHub] [camel-k] squakez commented on issue #2003: Revisit configuration options

Posted by GitBox <gi...@apache.org>.
squakez commented on issue #2003:
URL: https://github.com/apache/camel-k/issues/2003#issuecomment-841109505


   I am working on this.


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

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



[GitHub] [camel-k] astefanutti edited a comment on issue #2003: Revisit configuration options

Posted by GitBox <gi...@apache.org>.
astefanutti edited a comment on issue #2003:
URL: https://github.com/apache/camel-k/issues/2003#issuecomment-843983721


   Also, in that spirit of moving / "encapsulating" the configurability responsibility to the traits, it may be logical to:
   * Move the `.spec.repositories` field (Maven repositories) into the _builder_ trait
   * Move the `.spec.serviceAccountName` field into the _pod_ trait


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

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



[GitHub] [camel-k] astefanutti commented on issue #2003: Revisit configuration options

Posted by GitBox <gi...@apache.org>.
astefanutti commented on issue #2003:
URL: https://github.com/apache/camel-k/issues/2003#issuecomment-777557057


   I realise from https://github.com/apache/camel-k-runtime/pull/624, that any ConfigMap or Secret is (attempted to be) loaded as properties file.
   
   I'd agree with @lburgazzoli comment from https://github.com/apache/camel-k-runtime/issues/593:
   
   > I think the main issue is that we don't have a way to distinguish between configmaps and secrets used to store properties vs resources.
   
   It seems only application properties files should be mounted into the `conf.d` directory, while other ConfigMaps and Secrets should be mounted on the side. IIUIC, this is what would be for the `--config` and `--resource` options for.
   
   So currently, we have the ServiceBindings, ConfigMaps and Secrets mounted under the `conf.d` directory. Only the ConfigMaps and the Secrets added with the new `--config` option should be mounted there. The one added with the existing `--resource` should be mounted in `etc/camel/resources`. 
   
   That also means the existing `--configmap` and `--secret` options are removed.
   


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

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



[GitHub] [camel-k] lburgazzoli commented on issue #2003: Revisit configuration options

Posted by GitBox <gi...@apache.org>.
lburgazzoli commented on issue #2003:
URL: https://github.com/apache/camel-k/issues/2003#issuecomment-777565977


   Yep, I'd also add a new property function on camel-kruntime like `resource:name/key` to ease the process of loading resources.


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

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



[GitHub] [camel-k] squakez commented on issue #2003: Revisit configuration options

Posted by GitBox <gi...@apache.org>.
squakez commented on issue #2003:
URL: https://github.com/apache/camel-k/issues/2003#issuecomment-844840180


   > Also, in that spirit of moving / "encapsulating" the configurability responsibility to the traits, it may be logical to:
   > 
   >     * Move the `.spec.repositories` field (Maven repositories) into the _builder_ trait
   > 
   >     * Move the `.spec.serviceAccountName` field into the _pod_ trait
   
   Should we better create a separate issue in order to keep track of this?


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

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



[GitHub] [camel-k] squakez commented on issue #2003: Revisit configuration options

Posted by GitBox <gi...@apache.org>.
squakez commented on issue #2003:
URL: https://github.com/apache/camel-k/issues/2003#issuecomment-844839494


   > @squakez @nicolaferraro @astefanutti
   > 
   > wondering if we should create a `configuration` trait at this point so when we will implement #2165, we could also use the same mechanic to attach configuration properties to bindings, kamelets & what not
   
   Yes, that seems the best path to follow. As we must ensure compatibility, I may follow an approach where I will develop the feature minimizing the impact on the existing code, if I see it makes sense, and then encapsulating the logic into a separate trait.


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

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