-
Notifications
You must be signed in to change notification settings - Fork 290
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
Promote deployment finalization to stable #3025
Labels
difficulty/medium
medium complexity/difficutly issue
enhancement
reward/medium
Fixing this will be notably useful
triaged
This issue has been evaluated and is valid
Comments
Might be worth updating the description here now that we have #3077. |
cgwalters
added a commit
to cgwalters/ostree
that referenced
this issue
Nov 8, 2023
It's about time we do this; deployment finalization locking is a useful feature. An absolutely key thing here is that we've slowly been moving towards the deployments as the primary "source of truth". Specifically in bootc for example, we will GC container images not referenced by a deployment. This is then neecessary to support a "pull but don't apply automatically" model. Closes: ostreedev#3025
cgwalters
added a commit
to cgwalters/ostree
that referenced
this issue
Nov 20, 2023
It's about time we do this; deployment finalization locking is a useful feature. An absolutely key thing here is that we've slowly been moving towards the deployments as the primary "source of truth". Specifically in bootc for example, we will GC container images not referenced by a deployment. This is then neecessary to support a "pull but don't apply automatically" model. Closes: ostreedev#3025
cgwalters
added a commit
to cgwalters/ostree
that referenced
this issue
Nov 21, 2023
It's about time we do this; deployment finalization locking is a useful feature. An absolutely key thing here is that we've slowly been moving towards the deployments as the primary "source of truth". Specifically in bootc for example, we will GC container images not referenced by a deployment. This is then neecessary to support a "pull but don't apply automatically" model. This stabilizes the existing `ostree admin deploy --lock-finalization` CLI, and adds a new `ostree admin unlock-finalization`. We still check the old lock file path, but there's a new boolean value as part of the staged deployment data which is intended to be the source of truth in the future. At some point then we can drop the rpm-ostree lockfile handling. Closes: ostreedev#3025
cgwalters
added a commit
to cgwalters/ostree
that referenced
this issue
Nov 22, 2023
It's about time we do this; deployment finalization locking is a useful feature. An absolutely key thing here is that we've slowly been moving towards the deployments as the primary "source of truth". Specifically in bootc for example, we will GC container images not referenced by a deployment. This is then neecessary to support a "pull but don't apply automatically" model. This stabilizes the existing `ostree admin deploy --lock-finalization` CLI, and adds a new `ostree admin unlock-finalization`. We still check the old lock file path, but there's a new boolean value as part of the staged deployment data which is intended to be the source of truth in the future. At some point then we can drop the rpm-ostree lockfile handling. Closes: ostreedev#3025
cgwalters
added a commit
to cgwalters/ostree
that referenced
this issue
Nov 27, 2023
It's about time we do this; deployment finalization locking is a useful feature. An absolutely key thing here is that we've slowly been moving towards the deployments as the primary "source of truth". Specifically in bootc for example, we will GC container images not referenced by a deployment. This is then neecessary to support a "pull but don't apply automatically" model. This stabilizes the existing `ostree admin deploy --lock-finalization` CLI, and adds a new `ostree admin unlock-finalization`. We still check the old lock file path, but there's a new boolean value as part of the staged deployment data which is intended to be the source of truth in the future. At some point then we can drop the rpm-ostree lockfile handling. Closes: ostreedev#3025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
difficulty/medium
medium complexity/difficutly issue
enhancement
reward/medium
Fixing this will be notably useful
triaged
This issue has been evaluated and is valid
In #1841 we added "locking" for deployment finalization. It's way past time to promote this to a stable API.
One thing I think would be helpful here is to have the deployment lock change to become a symlink to the deployment that's locked. If that has changed, the lock no longer applies. This would solve an issue I continually hit:
systemctl stop zincati
And discover the rebase didn't work because we had a lingering lockfile.
Something like
ostree admin unlock-finalize
or so, and perhapsostree admin reboot --execute
that would itself invokesystemctl reboot
. Incidentally it may be nice to lower the "check for systemd inhibitors" here too.This is a bit more important now because I'd like to change things to have the deployments be source-of-truth (xref coreos/rpm-ostree#4391 )
Basically, this would make it all much easier to set up a flow (like zincati) which does:
The text was updated successfully, but these errors were encountered: