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. 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. Static UID/GID assignment requires more developer work but AFAICT it passes less potential issues off onto operators (which should be our goal). Cheers, Greg _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
