-
Notifications
You must be signed in to change notification settings - Fork 23
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
container: Cache new manifest/config in prepare, add API to query #537
Conversation
Closes: ostreedev#496 In coreos/rpm-ostree#4486 we were working on fixing `rpm-ostree upgrade --check` with containers. However, what we really want here is to *persist* the updated manifest (and config) that we fetch. And if we do that, we might as well just make it part of the current `prepare()` API so it happens automatically. In this change, we do so via detached commit metadata. An important thing here is that the data is then automatically lifecycle bound to the merge commit - and the merge commit always changes when we fetch a new manifest. Then, add this "cached update" metadata to the existing structure which has image state so it can be conveniently queried *without* re-fetching. Hence a flow like this should work: - OS boots - OS updater does a background "check for updates" via calling `prepare()` - OS updater finds an update, and renders metadata to the user or orchestration system - <time passes; OS update is not downloaded - e.g. user is on metered data or whatever> - system reboots for other reasons - OS updater can re-render the fact that a queued update was found *without* touching the network There's one notable piece that is missing to do conveniently: - User can initiate a full fetch (e.g. including image layers) targeting *exactly* the previously prepared fetch. This makes things much more race-free; if the image was GC'd in the meantime we correctly fail. But it can be done manually by e.g. using a digested pull spec temporarily.
2424df7
to
662aca0
Compare
OK, I think this is probably good...still doing some further testing with rpm-ostree but I think I'm narrowing in on the last mile of bugs there. |
Thinking about this a bit more, two potential issues:
|
Why not being able to check for updates from a read-only repo is an issue? |
The "read only repo" case happens to day on e.g. the FCOS Live ISO. You can do OK well, this doesn't work today (try with e.g.
And so this won't be a regression. |
As for "We don't offer a direct API to clear cached updates..." |
Yeah, one can use the low level ostree API to clear detached metadata entirely at least. |
In ostreedev/ostree-rs-ext#537 we added a facility to cache metadata (manifest+config) for container image updates with an eye for use in rpm-ostree. The `bootc update --check` code here in bootc was also updated to use it; but we didn't really expose it back in the status. This closes the gap, just bridging the cached update metadata into status. We want to do this as opposed to having `bootc update --check` grow its own API for example. Signed-off-by: Colin Walters <walters@verbum.org>
In ostreedev/ostree-rs-ext#537 we added a facility to cache metadata (manifest+config) for container image updates with an eye for use in rpm-ostree. The `bootc update --check` code here in bootc was also updated to use it; but we didn't really expose it back in the status. This closes the gap, just bridging the cached update metadata into status. We want to do this as opposed to having `bootc update --check` grow its own API for example. Closes: containers#247 Signed-off-by: Colin Walters <walters@verbum.org>
Closes: #496
In coreos/rpm-ostree#4486 we were working on fixing
rpm-ostree upgrade --check
with containers.However, what we really want here is to persist the updated manifest (and config) that we fetch. And if we do that, we might as well just make it part of the current
prepare()
API so it happens automatically.In this change, we do so via detached commit metadata. An important thing here is that the data is then automatically lifecycle bound to the merge commit - and the merge commit always changes when we fetch a new manifest.
In order to do an offline query (e.g. in rpm-ostree we want to re-synthesize a higher level summary of the queued update) add an API which allows querying a previously saved cached update.
Hence a flow like this should work:
prepare()