Atomic Updates - do we follow traditional model or a new one?

[James Antill]

On Tue, 2014-10-07 at 17:33 -0500, Joe Brockmeier wrote:
> Hey all,
> 
> One of the things that came out of the weekly meeting with infra/releng
> and folks working on Atomic is what I think may be a mis-match in
> expectations on upgrades/release process for the Atomic host.
> 
> As called out in the host definition[1] Atomic is planned as a rolling
> stream of updates - and users are expected to move to the next release
> in the stream rather than staying on a specific version or having to
> carry an overlapping stream.
> 
> That is: If you're on Fedora 21 Atomic, when Fedora 22 Atomic is
> released then that would be what you switch to - not a Fedora 21 tree.
> 
> I know for CentOS Atomic we won't be maintaining a set of overlapping
> releases, and I don't think RHEL will either. That sort of defeats the
> model, really.

 tl;dr I mostly agree with dgilmore here, and I think FESCO should too
at least in the short term ... but the users will be the final arbiters.

 At least one view of the model is that you have atomic upgrades, and
thus. rollback/downgrades. This fits perfectly with the f21/f21/f23
release model (although "rpm-ostree rebase" is very surprising when it
deletes your refs, you can still atomic downgrade).
 Certainly one of the benefits of ostree, to me, is that it should be
possible to freely move between N stable releases.

 I would also disagree strongly that RHEL will ever follow this model. I
would bet a huge amount of money that if customers are using the
official trees at all then enough of them will be willing to pay for
rhel8 after rhel9 goes live that it'll just happen.
 I'd also be willing to bet more than a few beers that if/when you
propose to PM that "rpm-ostree upgrade" magically changes the client
from rhel8 to rhel9 ... you will not be getting smiles and nods.

 As far as Fedora goes, it could be argued that it'd work better than
RHEL ... but again you have the change date problem. More than a few
people will want to move to Atomic 22 ASAP, the vast majority would
probably be happy moving as soon as F22 is released and then there are
some who'd prefer to wait N "seconds" after that.
 The only way to accommodate everyone here is going to be overlapping
releases. However maybe the breakdown is that 90% of users are happy
with it changing on F22 release day, so you can get away with just doing
that. Ironically though, I think the easiest way to get these stats. is
to have overlapping releases for a bit and see when the users move via.
the download stats. ... the less easy way being just doing it and see
how much it blows up :).

 As a minor note, if we do this we'll want some autoprune type
configuration added on the ostree layer.

>  (Also, there's not exactly an upgrade for Atomic
> something like F21->F22 if there are multiple trees, eventually you
> would have to manually switch trees if we were producing overlapping sets.)

 I don't see how this would be different at all, we are just changing
which commit we use ... why would it matter if it came from a different
ref or not? 

> In discussing this in today's meeting[2], Dennis suggested we'd need to
> go to FESCo to get agreement that we can pursue the non-overlapping
> model. Before I do that, I wanted to make sure we were all in agreement
> that is the way to go.
> 
> Thoughts, comments, flames?
> 
> [1] https://gist.github.com/jzb/0f336c6f23a0ba145b0a
> [2]
> http://meetbot.fedoraproject.org/atomic/2014-10-07/atomic.2014-10-07-18.09.txt