Open Stack

Hi

> On 7 Oct 2014, at 20:47, Clint Byrum <clint at fewbar.com> wrote:
>> 
>> I don't think it should import those files wholesale, IMO that's making way too many assumptions about the similarity of the two builds.
> Disagree on the grounds that the point of this is to deal with people
> who already have images and want to update them. We're not trying to
> enable people to deploy radically different OS's or anything like that.

My point is that we don't know what else is changing under the hood. Switching OS is a bit extreme, but we don't know that they're not going to pull in an OS upgrade at the same time and have everything change substantially, or even just introduce one additional dependency which we would destroy the uid/gid for.

>> I think this needs to be at least somewhat driven from the elements themselves - they need to declare the users/groups they need and likely offer a default UID/GID for each.
>> The element you describe could consult the elements to determine which users/groups need to be created, pull the values it needs from the passwd/group files if they exist, or fall back on the offered static defaults if not, then use normal tools to create the user/group (mainly so we respect whatever libnss settings the operator has chosen).
>> 
> 
> That is a lot of complexity for the case that we don't want people to
> use (constantly carrying /etc/passwd and /etc/group forward).

As tchaypo pointed out on IRC, if we do this static route, we are laying down a great big concrete slab of opinion in our images. I'm all for opinionated software, but we need to give people an out, which means we probably want to have a way for the suggested default UID/GIDs to be overridden, i.e. roughly what I described. We can just use that override to inject the pre-existing passwd/group values, if we so desire.

> I think that makes sense. The per-element expressions will still need
> to be coalesced into one place to check for conflicts. I suppose if we

Definitely. If we use normal system tools to create the users/groups, the build will fail if there are conflicts.

> So I think we still do care about these. MySQL puts its files on
> /mnt/state. RabbitMQ puts its files on /mnt/state. icinga puts its files
> on /mnt/state. If an element installs a package that needs a user, we
> have to treat that as our responsibility to handle, because we want to
> preserve /mnt/state.

Agreed. I just wanted to put a note on the table that we will have to care about these things :)

> It also has to have access to the previous image's /etc/passwd and
> /etc/group. In the context I wrote it in, updating via ansible, I can

*nods*

Cheers,

Chris