daemon/transaction-types: Support custom origins for digested pullspecs #5120
Conversation
|
This is what it looks like: |
|
Ahhh, I wasn't finding a good place to add an integration test for this, but I see
The alternative of course is to support something like |
rust/src/core.rs
Outdated
| && refspec.len() > (PREFIX_LEN + DIGEST_LEN) | ||
| && refspec[(refspec.len() - DIGEST_LEN - PREFIX_LEN)..].starts_with(PREFIX) | ||
| && ostree::validate_checksum_string(&refspec[(refspec.len() - DIGEST_LEN)..]).is_ok() |
There was a problem hiding this comment.
That feels like a bit manual string manipulations.
There was a problem hiding this comment.
Not opposed, but
(i.e. it means that something else is likely
managing the host and we want to reflect that info in the origin).
That goal seems to heavily overlap with the "driver" API to me...it's not so much that the origin is custom as it is that something else is managing.
A big difference versus the original thing we did here for the MCO/OCP case is that the admin couldn't upgrade via rpm-ostree "natively".
I guess another way to say this is: Is this purely cosmetic, and if so could we improve those cosmetics in another way?
Add a new `is_container_image_digest_reference()` function which checks if the container image pullspec is using a digest. Prep for next patch.
Almost no functional change (we do now error out if no description is given even if we're not going to use those fields, but that seems fine). Prep for next patch.
Having a digested pullspec is the container flow equivalent of an ostree checksum origin. So having a custom origin in that case is useful there for the same reasons (i.e. it means that something else is likely managing the host and we want to reflect that info in the origin). We're thinking of using this in FCOS when we move from OSTree to OCI for updates.
The rebase code already filters out the custom origin bits in cases where it doesn't make sense, so there's no need to additionally filter down here. This makes it work now in both the OSTree checksum case and the container digested pullspec case.
Now that we support this, let's make sure we render it as well.
Verify that one can use a custom origin with a digest pullspec. While we're here, use testing-devel instead of stable since it's going to be much closer to what we're running on.
jlebon
force-pushed
the
pr/custom-origin-containers
branch
from
d03ce28
to
a65b3af
Compare
Right yeah, this is a good distinction. I think there's a strong argument to be made that the "origin" in the FCOS case is indeed custom; the source of truth for what to update to is not an OSTree branch or container tag, but a graph. I used But yeah, this is definitely a big change in how things are wired today. Users currently can do Anyway, since this is already written up and seems generally useful, I tweaked it to address the comment! (Relatedly, I feel like we could open up custom origins to all methods? When using an agent, how rpm-ostree fetches the content seems separate from whether we want rpm-ostree to directly update from that same source.) |
Having a digested pullspec is the container flow equivalent of an
ostree checksum origin. So having a custom origin in that case is useful
there for the same reasons (i.e. it means that something else is likely
managing the host and we want to reflect that info in the origin).
We're thinking of using this in FCOS when we move from OSTree to OCI
for updates.