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 12:37:24 AM
> Subject: Re: [atomic-devel] Consiering a host UID/GID upgrade discontinuity (breaking CentOS7 Atomic and F22)
> 
> On Mon, May 4, 2015, at 12:18 PM, Joe Brockmeier wrote:
> >
> > Can we still do this change now? Does it impact anything else? (/me
> > wonders if we need a freeze exception or whatnot)
> 
> It's obviously a pretty gigantic freeze exception...but there's no
> access control, change management etc. over the "fedora-atomic"
> git repository (nor spin-kickstarts), just over the RPMs.
>  

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.

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.

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. Not just the read-only atomic filesystem either. You need to address any change on any filesystem that *might* be mounted in. Oh, and if the same drive is mounted to two different atomic images, the chown() calls aren't idempotent. Whee.

So yeah, the risks here seem pretty high, to me. 


> > Can we make sure to have this as a topic for Thursday's meeting (CentOS
> > SIG) and perhaps the Wednesday Cloud Working Group meeting (Fedora)? In
> > fact, we might need a Trac ticket for this w/in Fedora. Thoughts?
> 
> Yep, let's discuss in both.
> 
> For reference, I've attached the patch.  I tested it with a local tree
> compose
> and a rebase from RHELAH 7.1.1-1, it worked.
>