feat(cli): add gc command to manage IntegrationKits

[johnpoth]

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, running kamel gc -ry with Image Repository rights will result in the following IntegrationKit hierarchy:

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 #⁠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 #⁠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!

Release Note

NONE

[squakez]

Thanks for the contribution. I don't have a strong opinion. I feel we need to find a way to manage the proliferation of images when building an Integration, but, at the same time we need to leave the capacity of having intermediate layers that could be cached and reused by the operator.

I guess that the approach we're willing to take where the user test the Integration via camel jbang CLI locally and later run it submitting to the operator may make this feature superfluous. However, it can still be a good tool if the user knows what he's going to do. For instance, we may warn the user that by removing intermediary image, there could be a lower level of caching (so, a lower speed in deploying images).

Lastly, I'd avoid adding a new command, and instead use this as a subcommand of the kamel kit and add two different subcommands, squash and prune. If a user wants can either try to squash an Integration Kit or ask for pruning everything unused via separate commands.

[tadayosi]

Awesome contribution!

Lastly, I'd avoid adding a new command, and instead use this as a subcommand of the kamel kit and add two different subcommands, squash and prune. If a user wants can either try to squash an Integration Kit or ask for pruning everything unused via separate commands.

+1 for this. The name gc is already used as a trait name and overloading the meaning might become a cause of confusion. squash and prune are also used in Docker/Podman as exactly the same meanings as this feature so it would be most straightforward.

[github-actions]

This PR has been automatically marked as stale due to 90 days of inactivity.
It will be closed if no further activity occurs within 15 days.
If you think that’s incorrect or the issue should never stale, please simply write any comment.
Thanks for your contributions!