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: atomic-devel projectatomic io
> Sent: Wednesday, May 6, 2015 3:47:57 PM
> Subject: Re: [atomic-devel] Consiering a host UID/GID upgrade discontinuity (breaking CentOS7 Atomic and F22)
> 
> On Wed, May 6, 2015, at 03:22 PM, Stephen Gallagher wrote:
> > 
> > Strictly speaking, Fedora is not currently in a Freeze. Final Freeze starts
> > on Tuesday, May 12. However, we ARE past Beta release and making a change
> > like this so late in the release process is extremely risky, particularly
> > since if it breaks badly, either it slips Fedora or Fedora has to ship
> > without Atomic.
> 
> It was already decided that Atomic was non-blocking, though I don't have the
> reference to hand.
> 

Right, but that basically means that Atomic gets to ship as part of our release only if it's ready in time for everything else. I'm concerned that this change *at this time*, puts that at risk. I'd rather see Atomic ship without this change than miss the release for it.

> > Furthermore, breaking upgrades is a REALLY bad idea in general
> > (particularly for something like Atomic whose entire purpose is to be a
> > clean upgrade mechanism). I'm not sure a "universally agreed-upon" set of
> > IDs is worth making a change like that.
> 
> The benefit is being able to seamlessly rebase between the CentOS/RHEL Atomic
> Host and Fedora.
> 
> It sounds small...but it's a really big deal.
> 

No, I can certainly see how that would be huge. I'm not saying we shouldn't do this, just that the timing is problematic.

> > Let's also not forget that just updating the /etc/passwd and /etc/group
> > files is not sufficient. Any file on the system that was owned by those
> > IDs needs to be chowned.
> 
> The major ones here are things like /etc/ssh keys.  That's quite scriptable.
> 

Looking at the patch Joe provided, there's a lot of stuff being shuffled around here, including SSSD which, if it's being used, I know has a bunch of stuff in /var that would need adjusting.

> > Not just the read-only atomic filesystem either. You need to address any
> > change on any filesystem that *might* be mounted in.
> 
> This is like something where you store your ssh keys on /mnt/secrets which is
> a LUKS volume or something and have hand-configured sshd to look there
> and/or symlinked from /etc/ssh?
> 
> Yeah, could get ugly.  A transition script would probably need to be
> conservative.
> 


That's a single example (and one that we could easily handwave as "you broke it, you bought it"), but I suspect there are many other such examples we would only discover once they started breaking.

> > Oh, and if the same drive is mounted to two different atomic images, the
> > chown() calls aren't idempotent. Whee.
> 
> Rolling upgrades around shared data is definitely an issue.  On the other
> hand what you're arguing is effectively
> locking in Fedora-only upgrades now for the end of time.
> 
> What I'm arguing is it's far, far better to take this one time pain before
> deployment gets even larger.
> 

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.