> On 3 Oct 2014, at 02:57, James Polley <j...@jamezpolley.com> wrote:
>> On 3 Oct 2014, at 00:25, Clint Byrum <cl...@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@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack-dev mailing list

Reply via email to