Excerpts from James Polley's message of 2014-10-01 22:37:25 -0700: > All three of the options presented here seem to assume that UIDs will always > be allocated at image-build time. I think that's because most of these UIDs > will be used to write files into the chroot at image-create time - if I could > think of some way around that, I think we could avoid this problem more > neatly by not assigning the UIDs until first boot >
Yeah I don't think we're going to work around that. It is part of the magic of images that the metadata is all in place and there's no "churn" at boot. > But since we can't do that, would it be possible to compromise by having the > UIDs read in from heat metadata, and using the current allocation process if > none is provided? > I really, really dislike this. Post-boot tools like Heat are for per-server customization and site-wide changes. UIDs seem like plumbing under the hood. > This should allow people who prefer to have static UIDs to have simple > drop-in config, but also allow people who want to dynamically read from > existing images to scrape the details and then drop them in. > I see your point, and I'm now confused as I don't really understand what would make somebody prefer dynamic UID allocation. > To aid people who have existing images, perhaps we could provide a small tool > (if one doesn't already exist) that simply reads /etc/passwd and returns a > JSON username:uid map, to be added into the heat local environment when > building the next image? > Or a tool that reads the image, and returns /etc/passwd and /etc/group. Thanks very much for your thoughts. :) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
