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

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

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

   Thanks @johnpoth for understanding. Let me try to add some more information which I hope are good to put everybody on the same page. I agree we need to find some good solution to the problem of compacting the proliferation of containers, but it needs to be aligned with the design and the best practices we want to put in place.
   
   Let's start from the design. My concern is that we're allowing a direct access from the CLI to the Container Registry which may lead to inconsistencies. As an analogy, it would be like having a database application and let the UI directly alter the data bypassing the controller logic. If we want to add some API to manipulate the registry, this has to be done on top of the operator which is our controller. Let's imagine the situation where you're deleting an IntegrationKit. This is okey, and while deleting the related container image, this is failing because some network problem. We'd leave this in inconsistent state.
   
   The other important point is the fact that you really don't know who is using your container image. You're making the assumption that it's just linked to an Integration. However the reality is that the image could be used in any other cluster. I cannot see how really consistent could be the operation against a shared container image. We need to think this in a company which may have separate departments that may not necessarily know what each others are doing.
   
   In my opinion, a possible strategy for this feature could be to limit the discover of IntegrationKits and Builds which are no longer used and perform a prune of them warning the user that this could lead to inconsistencies anyway. Ideally we can output a list of images which are bound to those Kits as well, to be submitted for a registry cleaning. The cleaning of a container registry should be performed according to the policies of the companies and likely the departments in charge with their tools and scripts. Even if we provide this feature I hardly doubt that any company would use this in a production container registry so lightly.
   
   Finally a remark about the future of the CLI. It's true we are not dismissing it in the short term, but, the more work we add on the CLI now, the longer this term is getting. If we define and agree a roadmap is in order to provide a list of priorities on which we should focus. Planning and discussing take time, so, once we have some agreement for the year, we should follow it as much as we can. At this stage we have a lot of other priorities that would deserve developers attention IMO.
   
   Hope it clarifies.


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