[GitHub] [camel-k] johnpoth commented on pull request #4552: feat(cli): add kit prune and kit squash commands to manage IntegrationKits

["johnpoth (via GitHub)" <gi...@apache.org>]

johnpoth commented on PR #4552:
URL: https://github.com/apache/camel-k/pull/4552#issuecomment-1629167335

   Thanks for the feedback! Here are some comments inline
   
   > Thanks for the work done, but IMO there are a few points we should discuss:
   > 
   > 1. We decided in the roadmap development to limit the addition of feature in the CLI, trying to move as much as we can into Camel JBang. In the future we may remove at all the `kamel` cli. Adding more code that will be dismissed soon is not a good idea.
   
   So the idea here is to move this logic to the Operator in the future. For now, having this in the CLI gives us more control until we reach a state where this can be automated IMO.
   
   > 2. We are adding a lot of direct logic from the CLI to the registry directly. This is highly unsecure. We are already discussing the opportunity to change the way we access the registry from the operator via Spectrum (we're even discussing to deprecate it soon). In this PR we're having a direct access with go-containerregistry directly from the user CLI, neither from the operator. This is potentially dangerous.
   
   Why is this highly unsecure/potentially dangerous? As @lburgazzoli pointed out, a lot of projects use the Image Registry for storage. It is an exposed service after all. I am probably missing something though...
   
   > 3. I think that depending on the way the user is modelling its deployment, this could lead to inconsistencies. The `kamel promote` and several suggestions we've provided recently around GitOps are telling the user to share registry among namespaces and even among separate clusters. We cannot assume a Kit (and the container) is only used by a single namespace or even cluster.
   
   For sure! There is a [TODO](https://github.com/apache/camel-k/pull/4552/files#diff-867d7983c16e47d11bcf5f9458d20f7c786ecc2613d8d06ac685bff09eccaa5fR56) to add the Namespaces to search for. I guess a list of Clusters could be added to the list...
   
   > 4. Although the idea of squashing or deleting could be good from a user perspective it is quite a limitation for the operator. The possibility to reuse middle containers avoid the need to recreate from scratch. The more Kits an operator has available, the less work to recreate one from scratch will require.
   
   Agreed. That being said there has to be some strategy to limit the proliferation of Integration Kits as mentioned in other stories  (#254  and #2736) .... or is it no longer a bug, it's a feature?
   
   > 
   > I really appreciate the work done, but unfortunately it does not match the direction and the design choices we're trying to follow lately.
   
   All in all I agree it's important we are on the same page before solving the problem,
   
   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