Moving existing ostree users to a new branch - take 2

[Daniel Drake <drake endlessm com>]

Hi,

In a previous thread we started discussing how we might "end-of-life"
a current branch and redirect all its current users to a new one.

https://mail.gnome.org/archives/ostree-list/2017-March/msg00019.html

I started working on this and ran into a few difficulties, and also
decided to introduce some new design constraints to make the feature
better overall:

1. My idea of adding a "new commit type" doesn't make sense - a commit
is a commit. (I wrote that last mail before having looked at the
details.)

2. I tried adding commit metadata, but the implementation turned out
unclean. The pull/upgrade code is pretty flexible (and hence somewhat
complex), and having to insert logic to check the commit just pulled
and then go and pull something else was going to introduce a number of
corner cases, mess up the progress calculation, etc. Plus the
challenges noted by Colin about crossing layers, made more difficult
by the recent separation of "pull" and "deploy", it just wasn't going
to gel well with current code/design and we also wanted to avoid
changing libostree API.

3. We are looking to avoid having to maintain these EOL'd branches on
the server, and having the redirect in the commit metadata of the EOL
branch means we have to keep it there.

4. We're now looking to make sure this plays nicely with Philip
Withnall's LAN update work. If the connected server node goes online,
it would follow the EOL redirect and update to another branch. It
would purge the old branch at some point in future, at which point
not-updated LAN update clients would never see the redirect, so they'd
be abandoned on the old EOL branch.


Based on those thoughts I have a new proposal:

Instead of having the EOL branch itself present the redirect to the
new branch, do it the other way round: have the new branch note that
it is the replacement for EOL branches x, y and z.

This branch-replacement information would be present in the summary
file. The summary file continues being just a summary of other data,
so we need a canonical place to store this information. In my
prototype I'm storing it in the repo config but I'd welcome
suggestions of somewhere better to keep it.

The old EOL branches can be totally removed from the server.

Upon pull, the client reads the summary file and checks for the
redirect. If it finds the redirect, it pulls from the new branch
instead. It also then stores the replacement branch info locally (in
the same place where it is stored on the server - currently the repo
config).

Upon deploy, the client reads the replacement branch info and deploys
the new OS with the origin file updated to the new branch.

Working prototype here:
https://github.com/endlessm/ostree/commits/branch-eol-redirect

I'd be interested in any comments on the new design here, before we
start the full code review process.

Thanks!
Daniel