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

Reply via email to