Hi > On 7 Oct 2014, at 18:49, Clint Byrum <[email protected]> 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. 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). > * 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. > 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) > 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? Cheers, Chris _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
