> On 3 Oct 2014, at 00:25, Clint Byrum <[email protected]> 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 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
> [email protected]
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
