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

[Colin Walters <walters verbum org>]

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.

> 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.

> 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.

> 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.

> 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.