-
Notifications
You must be signed in to change notification settings - Fork 305
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
sysroot: Stabilize deployment finalization, add API #3090
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
38cfb61
to
04de1dd
Compare
src/libostree/ostree-deployment.c
Outdated
* @self: Deployment | ||
* | ||
* Returns: `TRUE` if deployment is queued to be "finalized" at shutdown time, but requires | ||
* additional action. Since: 2023.7 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* additional action. Since: 2023.7 | |
* additional action. Since: 2023.8 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is usually on its own line; not sure if it affects gobject introspection if it's not.
04de1dd
to
8d58901
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks sane overall! CI failure looks legit.
8d58901
to
36477ea
Compare
Hmm yes possibly, though I'm not reproducing this here. One thing this really brings to the fore is the huge messiness around gpg verification vs direct deployments and how |
Right now `ostree admin status` errors out in this case, but `rpm-ostree status` doesn't. The former behavior is probably more of a bug, work around it for now.
It's helpful to see which deployment has an error.
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
36477ea
to
28cc761
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
Some docs comments, but fine to leave as follow-ups to not waste CI.
|
||
<listitem><para> | ||
The deployment will not be "finalized" by default on shutdown; to later | ||
queue it, use <literal>ostree admin unlock-finalization</literal>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
queue it, use <literal>ostree admin unlock-finalization</literal>. | |
queue it, use <literal>ostree admin lock-finalization --unlock</literal>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, thanks for the careful review!
will be set into a "finalization locked" state, which means it will not be queued for the next boot by default. | ||
</para> | ||
<para> | ||
This is the same as the <literal>--lock-finalization</literal> argument for <literal>ostree admin deploy</literal>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feels like we should be more explicit about the race condition of not doing this. Maybe e.g.
This is the same as the <literal>--lock-finalization</literal> argument for <literal>ostree admin deploy</literal>. | |
This is the same as the <literal>--lock-finalization</literal> argument for <literal>ostree admin deploy</literal>, which is the recommended way to use this feature in a race-free way. |
?
Followup in #3100 |
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: #3025