[go: up one dir, main page]
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.

Sign up for GitHub

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

Jump to bottom

Local image expiry #1383

Open
stefanor opened this issue Nov 16, 2024 · 2 comments
Open

Local image expiry #1383

stefanor opened this issue Nov 16, 2024 · 2 comments

Comments

@stefanor
Copy link
Contributor

Incus expires remote images after a while, but there is no equivalent mechanism for local images.

I build my own images locally, occasionally. The latest image for each release gets an alias, taking it away from the previous image. It would be nice if there was a way to expire out the old images automatically. At the moment I have to do that manually.
@stgraber
Copy link
Member

That one is a bit tricky :)

We do have the concept of an image expiry that you can set through incus publish --expire DATE but that's something you set at image creation time and more meant to indicate an end of support than when the image should be auto-deleted.

In general I don't want us to try to be too smart about deleting images that didn't come from an external source as that could lead to straight up data loss.

How are your images generated? Are you using incus publish? If so, we could add a --delete flag which when combined with --reuse would delete the previous image for you.

@stefanor
Copy link
Contributor Author

My image building script is here: https://salsa.debian.org/-/snippets/750 So, image import, not publish.

I think what I'm looking for is something like an ephemeral flag on images. Where if it has no aliases, it's allowed to just expire away.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@stefanor @stgraber