Excerpts from Chris Jones's message of 2014-10-07 13:27:07 -0700: > Hi > > > On 7 Oct 2014, at 20:47, Clint Byrum <[email protected]> wrote: > >> > >> I don't think it should import those files wholesale, IMO that's making > >> way too many assumptions about the similarity of the two builds. > > Disagree on the grounds that the point of this is to deal with people > > who already have images and want to update them. We're not trying to > > enable people to deploy radically different OS's or anything like that. > > My point is that we don't know what else is changing under the hood. > Switching OS is a bit extreme, but we don't know that they're not going to > pull in an OS upgrade at the same time and have everything change > substantially, or even just introduce one additional dependency which we > would destroy the uid/gid for. >
Ok, any time we can fail at build time is good, so merging is important. I agree now. > >> I think this needs to be at least somewhat driven from the elements > >> themselves - they need to declare the users/groups they need and likely > >> offer a default UID/GID for each. > >> The element you describe could consult the elements to determine which > >> users/groups need to be created, pull the values it needs from the > >> passwd/group files if they exist, or fall back on the offered static > >> defaults if not, then use normal tools to create the user/group (mainly so > >> we respect whatever libnss settings the operator has chosen). > >> > > > > That is a lot of complexity for the case that we don't want people to > > use (constantly carrying /etc/passwd and /etc/group forward). > > As tchaypo pointed out on IRC, if we do this static route, we are laying down > a great big concrete slab of opinion in our images. I'm all for opinionated > software, but we need to give people an out, which means we probably want to > have a way for the suggested default UID/GIDs to be overridden, i.e. roughly > what I described. We can just use that override to inject the pre-existing > passwd/group values, if we so desire. > Mmk. I think having an override is important, but I feel that we can do it in a more straight forward manner. I may not have thought it all the way through. _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
