Open Stack

> The migrate_flavor_data command didn't actually work on the CLI (unless
> I'm missing something or did something odd). See
> https://review.openstack.org/#/c/175890/ where I fix the requirement of
> max_number. This likely means that operators have not bothered to do or
> test the migrate_flavor_data yet which could be a concern.

Yep, I saw and +2d, thanks. I think it's pretty early in kilo testing
and since you don't *have* to do this for kilo, it's not really been an
issue yet.

> That said, I'm surprised migrate_flavor_data isn't just done as a
> migration. I'm guessing there is a reason it's a separate tool and that
> it has been discussed before, but if we are going to have a migration
> enforcing the data to be migrated, then wouldn't it be sensible enough
> to just do it at that point?

The point of this is that it's *not* done as a migration. Doing this
transition as a DB migration would require hours of downtime for large
deployments while rolling over this migration. Instead, the code in kilo
can handle the data being in either place, and converts it on update.
The nova-manage command allows background conversion (hence the
max-number limit for throttling) to take place while the system is running.

Thanks for fixing up nova-manage and for making T-H aware!

--Dan