Open Stack

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

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?

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.

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?

> On 2 Oct 2014, at 11:50, Clint Byrum <clint at fewbar.com> wrote:
> 
> Recently we've been testing image based updates using TripleO, and we've
> run into an interesting conundrum.
> 
> Currently, our image build scripts create a user per service for the
> image. We don't, at this time, assert a UID, so it could get any UID in
> the /etc/passwd database of the image.
> 
> However, if we add a service that happens to have its users created
> before a previously existing service, the UID's shift by one. When
> this new image is deployed, the username might be 'ceilometer', but
> /mnt/state/var/lib/ceilometer is now owned by 'cinder'.
> 
> Here are 3 approaches, which are not mutually exclusive to one another.
> There are likely others, and I'd be interested in hearing your ideas.
> 
> * Static UID's for all state-preserving services. Basically we'd just
>  allocate these UID's from a static pool and those are always the UIDs
>  no matter what. This is the simplest solution, but does not help
>  anybody who is already looking to update a TripleO cloud. Also, this
>  would cause problems if TripleO wants to merge with any existing
>  system that might also want to use similar UID's. This also provides
>  no guard against non-static UID's storing things on the state
>  partition.
> 
> * Fix the UID's on image update. We can backup /etc/passwd and
>  /etc/group to /mnt/state, and on bootup we can diff the two, and any
>  UIDs that changed can be migrated. This could be very costly if the
>  swift storage UID changed, with millions of files present on the
>  system. This merge process is also not atomic and may not be
>  reversible, so it is a bit scary to automate this.
> 
> * Assert ownership when registering state path. We could have any
>  state-preserving elements register their desire for any important
>  globs for the state drive to be owned by a particular symbolic
>  username. This is just a different, more manual way to fix the UID's
>  and carries the same cons.
> 
> So, what do people think?
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev