openstack team mailing list archive

[Justin Santa Barbara <justin@xxxxxxxxxxxx>]

Indeed, migrations are a major fly in the ointment for any strategy for
meaningful naming (i.e. anything that doesn't use a central DB).  It's not
clear to me with cross-zone migrations that we (a) can keep the same ID and
(b) want to keep the same ID even if we could...

We could look at tricks like storing a 'redirect' pointer after a migration.
 I think it all boils down to our use-case for migrations:

   - If it's the cloud provider that notices that one machine is overloaded
   / failing / whatever and wants to move a VM to another host in the same
   zone, that should keep the same ID because it should be transparent to the
   user, and I think this shouldn't be a problem, because each zone has a DB.
   - If the cloud provider has a problem affecting an entire zone (e.g. 5
   more minutes of UPS power), can they live migrate those machines to another
   zone?  This could be problematic, and is where redirect pointers might have
   to come in.  So the 'parent zone' would have to know that 'childzone1' is
   down and those machines are potentially now scattered amongst other zones.
   - If it's the user that wants to migrate a machine e.g. because they are
   fed up with the AWS datacenter and want to go to a competitor, then we don't
   necessarily have to guarantee the same ID.  This presumes this is indeed a
   supported scenario; it may be that even if we make this easy, we don't
   support _live_ migration here.

Do we have any scoping on the use cases for migrations?

In my suggestion, I wasn't really talking about an external registry (other
than DNS to locate the top-level zones)  I don't think my proposed solution
addresses the issue of changing IDs in cross-zone migrations.

Looks like we might need an extended session for this at the Design Summit
:-)

Justin