Open Stack

> If there are ongoing migration then defaulting the consumer type to 
> instance might be incorrect.

Right, and you have to assume that there are some in progress. Only Nova
has the ability to tell you which consumers are instances or
migrations. If we did this before we split, we could have looked at the
api db instance mappings to make the determination, but I think now we
need to be told via the API which is which.

> However nova already has a mechanism to distingush between migration
> and instance consumer so nova won't break by this.

This would mean placement just lies about what each consumer is, and an
operator trying to make sense of an upgrade by dumping stuff with
osc-placement won't be able to tell the difference. They might be
inclined to delete what, to them, would look like a bunch of stale
instance allocations.

> Still nova might want to fix this placement data inconsistency. I
> guess the new placement microversion will allow to update the consumer
> type of an allocation.

Yeah, I think this has to be updated from Nova. I (and I imagine others)
would like to avoid making the type field optional in the API. So maybe
default the value to something like "incomplete" or "unknown" and then
let nova correct this naturally for instances on host startup and
migrations on complete/revert. Ideally nova will be one one of the users
that wants to depend on the type string, so we want to use our knowledge
of which is which to get existing allocations updated so we can depend
on the type value later.

--Dan