Open Stack

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. :)