Open Stack

Excerpts from Chris Jones's message of 2014-10-07 12:23:20 -0700:
> Hi
> 
> > On 7 Oct 2014, at 18:49, Clint Byrum <clint at fewbar.com> wrote:
> > * Create an element which imports /etc/passwd and /etc/group from local
> > disk into image. This will have an element-provides of uid-gid-map
> 
> 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.

> 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).

> > * Create a separate element called 'static-users' which also provides
> > uid-gid-map. Contains a map of uids and gids, and creates users early on
> 
> I don't like the idea of keeping the map in a single element, for several reasons:
>  1: Harder to maintain across multiple element repos (e.g. we have two repos, do we have a static-users equivalent in each?)
>  2: Harder for downstreams to fork if they want to add an element we don't carry
>  3: Harder for devs to commit to, especially if it means they need to simultaneously land something in di-b and t-i-e.
> 

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
use "add only" tools that will work.

> > with static UIDs/GIDs only. Disables usual commands used to add users and
> > groups (error message should explain well enough that user can add their
> 
> Are you suggesting disabling those during build time only, or runtime too? I strongly dislike the latter and I'm not thrilled about the former. I'd rather we leave them as-is and audit the passwd/group files at the end of the build, vs what we were expecting from the elements.
> 
> (we should also be aware that by enforcing this, we'll be increasing the number of elements we need to supply, because any dependencies that get pulled in during the build, which create users/groups, will now error/fail the build)
> 

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.

> > As for migrations, that is fairly simple and can be done generically,
> > I've already written a script that does it fairly reliably. The only
> 
> Curious to see how that works - how can it know that /mnt/state/some/random/dir currently listed as "ceilometer" was actually owned by "swift" on the previous boot?

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
cheat and copy that into /mnt/state before rebuilding the box. But we
can do that in our elements too. :)