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

Promote deployment finalization to stable #3025

Closed
cgwalters opened this issue Aug 31, 2023 · 1 comment · Fixed by #3090
Closed

Promote deployment finalization to stable #3025

cgwalters opened this issue Aug 31, 2023 · 1 comment · Fixed by #3090
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
Copy link
Member

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
  • rpm-ostree rebase
  • systemctl reboot

And discover the rebase didn't work because we had a lingering lockfile.

Something like ostree admin unlock-finalize or so, and perhaps ostree admin reboot --execute that would itself invoke systemctl 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:

  • pull and stage (and lock) updates
  • opt-in unlock+apply
@cgwalters cgwalters added enhancement difficulty/medium medium complexity/difficutly issue triaged This issue has been evaluated and is valid reward/medium Fixing this will be notably useful labels Aug 31, 2023
@jlebon
Copy link
Member

jlebon commented Nov 7, 2023

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
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants