Re: [atomic-devel] Consiering a host UID/GID upgrade discontinuity (breaking CentOS7 Atomic and F22)

[Stephen Gallagher <sgallagh redhat com>]

----- Original Message -----
> From: "Colin Walters" <walters verbum org>
> To: "Stephen Gallagher" <sgallagh redhat com>
> Cc: atomic-devel projectatomic io
> Sent: Wednesday, May 6, 2015 4:33:45 PM
> Subject: Re: [atomic-devel] Consiering a host UID/GID upgrade discontinuity (breaking CentOS7 Atomic and F22)
> 
> On Wed, May 6, 2015, at 04:22 PM, Stephen Gallagher wrote:
> > 
> > No, I think you're absolutely right that we need to fix this before it goes
> > too far, but my concern is that it's already too late to do it for this
> > cycle. I think what you need to do is make that change in Rawhide
> > immediately and work with docs, marketing and Ambassadors to let people
> > know that Fedora 22's release won't be future-compatible with Fedora 23
> > and CentOS, but changes are being made to avoid such breakage in the
> > future. This gives you time to optimize the migration plan and users
> > awareness of the upcoming one-time hassle.
> 
> I see you arguing two somewhat contradictory things here.  First, you are
> (correctly) arguing that a reliable transition is hard.  Your examples of
> system uid data on NFS/etc is a good one.
> 
> Then you're arguing that it makes sense to do in F23.  Do we really expect
> that the additional time will allow a sufficiently robust script to be
> developed?
> 

No, I didn't mean to imply that. I meant to say that since a sufficiently robust script is likely *impossible*, we should take extra time for messaging this as an upcoming bump in the road.


> One other *major* factor to consider here - Fedora 21 only shipped a Atomic
> as a cloud image, and while one can certainly possible to treat them as
> pets, I suspect the majority treat them as cattle - disposable, data is
> stored on externally mounted volumes, so you can "upgrade" without ostree by
> just booting a new image.
> 
> But Fedora 22 will ship (hopefully) Atomic as a bare metal installer.  And
> it's a lot more common to have bare metal pets[1].  I'd argue that the
> strengths of OSTree really come much more to the fore when used on bare
> metal.  So I'd like to ensure these installations will be upgradeable
> forever.
> 

Hmm, if there's really no expectation that F21 users would *want* to upgrade to F22, then I suppose my concern is somewhat alleviated. Yeah, this will break folks who were testing Beta, but that's a known risk of pre-release stuff.

How confident are you that you can ensure that everything in the shipping image/installer has the right IDs before the Final Freeze? I suppose I can be on-board with this if you're sure about the fallout (or at least have a plan like "Revert this on Monday morning if it's not perfect by then"). I don't want this potentially impacting Freeze (and yes, while I know it's not blocking on its own, dealing with Freeze Exception requests to unbreak issues this causes can still be destabilizing for the rest of the system). We really want to release on time (since F21 was such a runaway train of slippage).


> [1] There are some times in computing where what one writes must sound really
> quite strange to those outside of the industry.

Hehe