How is cachedUpdate calculated?

[beav]

I saw that cachedUpdate was added in #248. I see that the various states of rollback, booted, etc each have their own cachedUpdate.

What is the best way to figure out what image digest a system will receive on the next bootc upgrade? I'm not sure which cachedUpdate to use in the status response.

[jeckersb]

You can't definitively know which digest a system will get on the next bootc upgrade, because it will check again to see if there's an update available. You could have a scenario like:

1. System is booted/running with image foo with digest A
2. bootc upgrade --check is run, which receives metadata about a new version of foo with digest B. This will be reflected under status.booted.cachedUpate.
3. A new version of foo is published with digest C
4. bootc upgrade is run.

The status object is not going to reflect anything about C until after the last bootc upgrade is run.

[beav]

Is it possible to optionally specify an image hash to bootc upgrade? This would help with the above race condition since the upgrade can then either succeed or fail if the hash isn't there.

More generally, I was originally thinking that upgrades would have image hash status in five places:

1. the actual bits in the upstream OCI registry
2. what is in cachedUpdate on the system
3. what's in staged
4. what's in booted
5. what's in rollback

Hashes would then "flow" from 1 to 5 by performing various steps, and if something goes awry, the rollback will backflow to booted. A bootc switch would alter the flow but I believe would just change 1 to 3.

Is this model correct? I think at minimum if I'm using status.booted.cachedUpdate for step 2, I may have incorrect state after a switch until I reboot.

[cgwalters]

Yeah, though we can add bootc upgrade --from-cached or so?

[beav]

Yeah, though we can add bootc upgrade --from-cached or so?

I could see this flag being useful. The ability to pass the image hash is also useful though so we can guarantee you're either getting hash X installed, or it will fail. An example would be if I was sequentially rolling out a bugfix to systems in a cluster via script and needed to ensure they all had the same hash.

[jeckersb]

I think if you want to target a specific hash that you know ahead of time, the most direct approach is to just set spec.image.image to that particular hash (via bootc switch or bootc edit). Much easier than trying to follow an ever-changing tag while also trying to synchronize on a particular hash.

[cgwalters]

Right, but the slightly tricky thing there is that the thing determining the digest to target must then also try to perform the fetch on its own (reusing the same authentication credentials, etc.)

[cgwalters]

I guess one thing we could try to do is have a workflow that supports both tag and @sha256 digest. There's been some movement for that in the container ecosystem. (It may actually work right now, need to experiment)

But if we do that it would lead us towards supporting a flow where external tooling can pin to a digest, but bootc upgrade --fetch would use the tag instead and look for updates there. Then higher level tooling can then explicitly target the new digest for upgrades.