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

   <!-- Description -->
   
   Hi all,
   
   This PR proposes a solution at our IntegrationKit cleanup problem (see 
#2736, #254).
   
   This adds a new `gc` command in the kamel CLI that will cleanup unused 
integration kits. For example, in @joes [use 
case](https://github.com/apache/camel-k/issues/2736#issuecomment-974038930), 
running `kamel gc -ry` with Image Repository rights will result in the 
following IntegrationKit hierarchy:
   
![mermaid-diagram-2023-01-12-144229](https://user-images.githubusercontent.com/7074290/212082316-8bedaf2a-8fdb-4800-aa68-7b9ca5337e95.png)
   
   Images will be deleted from the Image repository and intermediate layers in 
`camel-k-kit-c68qat0oipt5te3mr3h0` will be squashed into a _single_ layer . 
This will trigger the integration _camel-integration-platform/oep-invoices_  to 
be _redeployed_ with the new squashed image.
   
   If we don't have Image Repository delete rights then only the unused 
Integration Kits CRs will be removed. An integration kit is considered unused 
if not referenced by an integration.
   
   The command will return an error if new IntegrationKits are being built.
   
   This eventually should be running in the Operator but for more control and 
awaiting initial feedback, it's only in the CLI.
   
   - TODO:
       - [ ] Add more tests 
       - [ ] Move to command to `kamel kit gc` if no other resources are being 
garbage collected
       - [ ] If we don't have Image Repository rights, output list of Images to 
be deleted manually
   
   This begs the question of how far we want to go with this? Do we want to 
simply delete IntegrationKit CRs or do we want to also manage the Images ? I 
added an option to switch between the two strategies but the bulk of the code 
is for managing images.
   
   ### Proposal #&#x2060;2:
   A completely different way of dealing with this would be to add a `--dev` 
option when running integrations. This would put the integration and 
integrationkit into a `dev` state:
   * When the integration changes, the same integrationkit and image repository 
would be reused 
   * The IntegrationKit in a `dev` state can not be used as a base image due to 
it's changing nature
   * There would be a 1:1 relationship between the integration and 
integrationkit 
   
   Removing the `dev` state would revert to the current behavior. I feel like 
this approach goes well with CI/CD and should results in less complexity. 
   
   All in all #&#x2060;2 seems like a better way of dealing with the issue but 
the two solutions aren't necessarily mutually exclusive.  
   
   Let me know what you think ! Thanks!
   
   <!--
   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
   NONE
   ```
   


-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to