Open Stack

Excerpts from Gregory Haynes's message of 2014-10-06 07:06:02 -0700:
> Excerpts from Clint Byrum's message of 2014-10-02 14:15:30 +0000:
> > Excerpts from Gregory Haynes's message of 2014-10-01 19:09:38 -0700:
> > > If we really want to go with this type of aproach we could also just
> > > copy the existing /etc/passwd into the image thats being built. Then
> > > when users are added they should be added in after existing users.
> > > 
> > 
> > I do like this approach, and it isn't one I had considered. We will know
> > what image we want to update from in nearly every situation. Also this
> > supports another case, which is rolling back to the previous image,
> > quite well.
> > 
> > Really this is just an automated form of static UID assignment.
> > 
> 
> Now that ive proposed this id like to make an argument against the copy
> /etc/passwd as our long term solution (sorry). I do think its a not bad
> immediate fix, but long term id prefer actual static UID assignment out
> of the solutions proposed so far.
> 

We have to be _extremely_ careful in how we manage this. I actually think
it has potential to really blow up in our faces. We need to give people
a way to move forward without us merging a patch, and at the same time
we need to make sure we provide a consistent set of UIDs for anything
people may want to deploy with diskimage-builder.

> It seems like determining how to build a new image based on the state of
> a previous image is an exact anti-pattern that read only / ephemeral
> instances aim to solve - minimize entropy collected over time from doing
> updates. Were also adding a requirement that user databases are now
> precious data which cannot ever be lost for a given image type. Its
> worth noting that these are both issues that operators will encounter.
> 

I disagree with some of these points. Expecting Linux filesystems to
be consumable from any machine without a source of consistent UIDs/GIDs
is the anti-pattern. Using /etc/passwd and /etc/group from the previous
image is just one such source, and it is one source that anybody who has
a previous image will always have.

If you've deployed using TripleO's tools already, you will not have
the same UIDs that our centralized UID registry would have. We could
also just deploy FreeIPA on all controllers, delay UID allocations, and
put everything in LDAP. Having our own special project for static UIDs
feels like a third possible implementation, not one I'm ready to say is
"the way".

I'm leaning more toward keeping a copy of the UID/GID/symbolic-name
database anywhere that has state, and use a guard against making use of
a system database which conflicts with existing mappings on the state
drive. Then we can use either a static UID project, or previous images,
as the source of UIDs/GIDs for new images, to avoid hitting the guard.

> Static UID/GID assignment requires more developer work but AFAICT it
> passes less potential issues off onto operators (which should be our
> goal).


+1 for making this as painless as possible on operators.