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 _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
