Enhance support for deploying older commits

[mbarnes]

Filing this issue as a place for discussion.

Here's a rough prototype of what I had in mind:
https://github.com/mbarnes/ostree-scripts/blob/master/clunky-rebase

Basically I'm extending rpm-ostree rebase with new options to allow rebasing to a specific commit. The commit can be specified by checksum or version tag. See the comment block in the script for syntax changes. e.g.

rpm-ostree rebase --version=7.1.3

The new extension involves a recursive pull of commit metadata for a branch in order to look up checksums or version tags. Obviously this is not the most efficient approach and I made some notes about that in the script, but I'm also open to other ideas. I believe this is the first time we've attempted to reference a commit by its version tag.

[stefwalter]

In the OSTree UI for Cockpit we display update and rollback trees and then allow the user to perform the action to upgrade or rollback to them.

https://github.com/cockpit-project/cockpit/wiki/Atomic:-OSTree-Update

https://raw.githubusercontent.com/cockpit-project/cockpit-design/master/software-updates/software-updates-ostree-alt.png

Obviously we want to upgrade or rollback to those specific trees that are being displayed. It would be a big no-no to have the user click 'Update and reboot' on a certain tree, and we then update to something completely different.

Is the work you've done here what we need in order to make that UI work?

[cgwalters]

Updating OstreeSysrootUpgrader to support this would make sense to me.

[mbarnes]

@stefwalter The use case for this work is to revert back to any older atomic host release. I suppose you could use this for rollback and possibly upgrade, but as long as Cockpit is accurately displaying the current OSTree deployments you should be fine with the Upgrade() and Rollback() methods.

[mbarnes]

@cgwalters What do you think about the way I'm looking up versions? I expect that's the controversial part.

[petervo]

There is race in the UI with upgrades, both in cockpit and the cli., basically you "check for updates" and look those over, then click "update". If in the in between time between those 2 options a new commit was added to your remote tree you'll end up installing that one instead of the commit you looked over.

@cgwalters suggestion of adding support to OstreeSysrootUpgrader seems like a good fix.

[mbarnes]

We could add a (optional?) checksum argument to the Upgrade() and Rollback() methods that just verifies we know what we're upgrading or rolling back to before doing so, while the daemon holds the sysroot lock so nothing can interfere.

Best we move the UI race to a separate issue.

[cgwalters]

I'd like to support refs/commits and versions. Currently though we don't have an unambiguous syntax for a string which could be either. I was thinking version:1.2.3 but the problem is that looks like a refspec with remote version and branch 1.2.3. Maybe version=1.2.3 since = is not presently allowed in remote names?

As far as retrieving the whole history to find a version...that will presently be a notable hit on Fedora at least which does an arbitrary once-per-day tree commit, and would be very expensive for gnome-continuous which has...

ostree --repo=repo log gnome-continuous/buildmaster/x86_64-devel-debug |grep '^commit' | wc -l
31719

commits.

I can definitely see versions being nice, but just like I use git commit hashes a lot, I don't think it's totally crazy to expect system administrators to occasionally use ostree commit hashes =)

[mbarnes]

I had played around with version=1.2.3 syntax and had even generalized it to any metadata key, but it started to feel a bit over-engineered for a simple "rebase to version blah" use case. I didn't want to end up with something like --revision=version=1.2.3.

Retrieving the whole history to find a version is obviously stupid, but it's a starting point. I was working with what's available. I noted in the script it would be nice to short-circuit the recursive pull when we find what we're looking for, so the download size is a function of how far back you're going. Even nicer would be to just consult an index somewhere, but we don't have that.

I think referencing versions is compelling just because of how difficult is it to find out checksums for commits that are not on your local machine. ostree log is of no help currently. For my demo today I actually had to write a script to pull down those old rhel-atomic-host checksums.

But to keep things moving we could split this into just getting the rebase enhancement in place using our normal revision syntax and then maybe tackle version lookups later as a separate feature.

[cgwalters]

For RHEL Atomic Host you can find the commits in the errata messages/bugzilla. See for example: https://bugzilla.redhat.com/show_bug.cgi?id=1246575

[cgwalters]

But I agree versions are good, and I am OK with history traversal, we can fix that later.

[cgwalters]

This was done.