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

sysroot: Stabilize deployment finalization, add API #3090

Merged
merged 3 commits into from
Nov 27, 2023

Conversation

cgwalters
Copy link
Member

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

Copy link
Collaborator

@ericcurtin ericcurtin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

* @self: Deployment
*
* Returns: `TRUE` if deployment is queued to be "finalized" at shutdown time, but requires
* additional action. Since: 2023.7
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* additional action. Since: 2023.7
* additional action. Since: 2023.8

Copy link
Member

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.

src/libostree/ostree-sysroot-deploy.c Show resolved Hide resolved
Copy link
Member

@jlebon jlebon left a 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.

man/ostree-admin-unlock-finalization.xml Outdated Show resolved Hide resolved
man/ostree-admin-unlock-finalization.xml Outdated Show resolved Hide resolved
@cgwalters
Copy link
Member Author

CI failure looks legit.

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 ostree admin status bails out with an command-fatal error versus what rpm-ostree does in just showing the error as part of state gathering.

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
Copy link
Member

@jlebon jlebon left a 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>.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
queue it, use <literal>ostree admin unlock-finalization</literal>.
queue it, use <literal>ostree admin lock-finalization --unlock</literal>.

Copy link
Member Author

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>.
Copy link
Member

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.

Suggested change
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.

?

@cgwalters cgwalters merged commit 12cbb3d into ostreedev:main Nov 27, 2023
24 checks passed
@cgwalters
Copy link
Member Author

Followup in #3100

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Promote deployment finalization to stable
3 participants