Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Camel-K operator should clean up kits and kit builders after integrations are deleted #889

Closed
bfitzpat opened this issue Jul 30, 2019 · 7 comments
Assignees
Labels
area/build-operator Related to the internal image build operator status/stale
Projects
Milestone

Comments

@bfitzpat
Copy link
Contributor

Now that adding a new integration creates a camel-k-kit-* and camel-k-kit-*-builder along with the integration pod itself, it seems there should be some clean up to remove those when the integration is deleted? I'm seeing the custom resource/integrationkits still hanging around after I remove the integrations.

@bfitzpat
Copy link
Contributor Author

Running kamel reset does help clean up the errant artifacts, so that's a good workaround in the short term.

@nicolaferraro nicolaferraro added this to the 1.0.0-M5 milestone Nov 22, 2019
@nicolaferraro nicolaferraro modified the milestones: 1.0.0-M5, 1.0.0-CR1 Dec 3, 2019
@nicolaferraro nicolaferraro modified the milestones: 1.0.0-CR1, 1.0.0-CR2 Dec 13, 2019
@astefanutti astefanutti added the area/build-operator Related to the internal image build operator label Feb 11, 2020
@astefanutti astefanutti added this to To do in Build Feb 11, 2020
@lburgazzoli
Copy link
Contributor

It should certainly clean-up builder but kits need to be kept as they are needed to properly determine how and if new container images have to be built

@nicolaferraro nicolaferraro modified the milestones: 1.0.0-RC2, 1.0.0-future Feb 20, 2020
@nicolaferraro nicolaferraro added the good first issue Does not require full understanding of the codebase label Mar 16, 2020
@dhirajsb dhirajsb self-assigned this Mar 26, 2020
@dhirajsb
Copy link
Member

There seems to be an underlying assumption that the user will run the same integration again and hence the kit needs to be kept around.

Doesn't that lead to the following:

  • Deleting an integration completely is a two step process, delete the integration then deleting the kit separately.
  • If a user deletes an integration without knowing that kit has to be deleted separately, kits will start piling up in the background, since kamel get only lists integrations.

I think the integration lifecycle is kinda ambiguous, since running an integration both builds, deploys and runs it, and there is no clean state transition to deleting an integration completely.

At a higher level, there is a disconnect from when an integration comes into existence (preferably in a vcs), to being run using kamel.

dhirajsb added a commit to dhirajsb/camel-k that referenced this issue Apr 20, 2020
@lburgazzoli
Copy link
Contributor

There seems to be an underlying assumption that the user will run the same integration again and hence the kit needs to be kept around.

An integration kit is by design not tight to a specific integration but can be reused by any other integration that requires the same set of dependencies or it can be used as base image for a subsequent build to reduce the amount of data transferred from/to the registry, that's why kits are not deleted along with integrations.

@astefanutti
Copy link
Member

One approach would be to implement a GC-like mechanism that would run periodically and remove the unreferenced kits, created since longer than a configurable period of time. Otherwise, we can add a prune-like operation to the Kamel CLI that would ease removing the kits.

@lburgazzoli
Copy link
Contributor

lburgazzoli commented Apr 20, 2020

There's actually a quite old issue: #254

dhirajsb added a commit to dhirajsb/camel-k that referenced this issue Apr 21, 2020
@nicolaferraro nicolaferraro modified the milestones: 1.0.0, post 1.0.0 Jun 3, 2020
@nicolaferraro nicolaferraro modified the milestones: 1.3.0, 1.4.0 Dec 22, 2020
@nicolaferraro nicolaferraro modified the milestones: 1.4.0, 1.5.0 Mar 16, 2021
@nicolaferraro nicolaferraro modified the milestones: 1.5.0, 1.6.0 Jul 5, 2021
@nicolaferraro nicolaferraro modified the milestones: 1.6.0, 1.7.0 Sep 7, 2021
@nicolaferraro nicolaferraro removed this from the 1.7.0 milestone Nov 15, 2021
@nicolaferraro nicolaferraro added this to the 1.8.0 milestone Nov 15, 2021
@oscerd oscerd modified the milestones: 1.8.0, 1.9.0 Jan 19, 2022
@astefanutti astefanutti removed the good first issue Does not require full understanding of the codebase label Mar 28, 2022
@oscerd oscerd modified the milestones: 1.9.0, 1.9.1 Apr 26, 2022
@oscerd oscerd modified the milestones: 1.9.1, 1.9.2 May 13, 2022
@oscerd oscerd modified the milestones: 1.9.2, 2.0.0 May 23, 2022
@github-actions
Copy link
Contributor

This issue 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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/build-operator Related to the internal image build operator status/stale
Projects
No open projects
Build
  
To do
Development

No branches or pull requests

6 participants