On 8 October 2014 06:49, Clint Byrum <[email protected]> wrote: > Excerpts from Chris Jones's message of 2014-10-07 04:35:33 -0700:
>> AFAICS, the only risk left at that point, is elements that other people are >> maintaining. If we consider that to be a sufficient risk, we can still build >> the mechanism for injecting ID values from a previous build (essentially >> just seeding the static values that we'd be setting anyway) and apologise to >> the users who need that, or who don't discover its existence and break their >> clouds. > > I'm not afraid of running migrations once. I want to make sure we never > _plan_ to run migrations as part of regular operation. If I can make a suggestion... Set a marker in the image indicating whether it has fixed uuids or not. Calculate that by comparing the contents of the computed passwd and groups db's to the static reference we've put together. Secondly, at the end of migrations.d write a marker file in /mnt/state that indicates we're fully synced. This flag should contain a uuid of the image and whether or not that image had fixed ids - or something like that. Then, the chown migration should activate if either a) the image doesn't have fully fixed uuids, or b) the marker file is missing, or c) the marker file has a different uuid and indicates the prior image didn't have fixed ids. -Rob -- Robert Collins <[email protected]> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
