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
cgwalters
added
enhancement
difficulty/medium
|
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
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 zincatiAnd discover the rebase didn't work because we had a lingering lockfile.
Something like
ostree admin unlock-finalizeor so, and perhapsostree admin reboot --executethat 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: