Open Stack

> On 3 Oct 2014, at 02:57, James Polley <jp at jamezpolley.com> wrote:
> 
> 
> 
> 
> 
>> On 3 Oct 2014, at 00:25, Clint Byrum <clint at fewbar.com> wrote:
>> 
>> 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.
> 
> Agree - it would be quite a significant change in how TripleO works, not just a workaround.
> 
>> 
>>> 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.
> 
> I think that the part of this you dislike is specifically storing the data in heat?
> 
> Would you object less if I phrased it as "a job file to be read at image build time", which is closer to what I had in mind?
> 
>> 
>>> 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.
> 
> I was thinking of a case where an operator might have several existing images with different sets of services, or different base distribtions, and hence different sets of uids; they'd probably prefer to have the build process extract the details from the previous image rather than having a single fixed map of uids.

> Someone starting fresh might prefer to provide a static map of pre-assigned UIDs

To be clear - I don't think either of these is novel - these are cases 1 and  2 from the mail that started the thread.

The point I'm ineptly trying to make (why am I sending email at 3am?) is that I think we can easily support both 1 and 2 simply by thinking of "read list of UIDs from an existing image" and "apply existing list of UIDs to new image" as separate tasks and implement both separately 

> 
> 
>>> 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.
> 
> Sure, but I think it would be handy if it could accept data from another source as well as the previous image, to cater for people who want to be more prescriptive about which UIDs are used but don't have adv Bing existing image yet.
> 
> I don't know if this is a real use case though - maybe I'm just remembering bad experiences from a previous pre-cloud life.
> 
>> 
>> Thanks very much for your thoughts. :)
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev