Hi

> On 7 Oct 2014, at 20:47, Clint Byrum <cl...@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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to