On 8 October 2014 06:49, Clint Byrum <cl...@fewbar.com> 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.


Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

OpenStack-dev mailing list

Reply via email to