> 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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
