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.
