Open Stack

On 4/22/15 1:20 AM, Dan Smith wrote:
>> 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.

Sure, but for people doing continuous deployment, they clearly haven't 
ran the migrate_flavor_data (or if they have, they haven't filed any 
bugs about it not working[0]).

I also found what I believe to be a bug with the flavor migration code. 
I started working on a fix by my limited knowledge of nova's objects has 
hindered me. Any thoughts on the legitimacy of the bug would be helpful 
though: https://bugs.launchpad.net/nova/+bug/1447132 . Basically for 
some of the datasets that turbo-hipster uses there are no entries in the 
new instance_extra table stopping any flavor migration from actually 
running. Then in your change (174480) you check the metadata table 
instead of the extras table causing the migration to fail even though 
migrate_flavor_data thinks there is nothing to do.

I think it's worth noting that your change (174480) will require 
operators (particularly continuous deployers) to run migrate_flavor_data 
and given the difficulties I've found I'm not sure it's ready to be ran. 
If we encounter bugs against real datasets with migrate_flavor_data then 
deployers will be unable to upgrade until migrate_flavor_data is fixed. 
This may make things awkward if a deployer updates their codebase and 
can't run the migrations. Clearly they'll have to roll-back the changes. 
This is the scenario turbo-hipster is meant to catch - migrations that 
don't work on real datasets.

If migrate_flavor_data is broken a backport into Kilo will be needed so 
that if Liberty requires all the flavor migrations to be finished they 
can indeed be ran before upgrading to Liberty. This may give reason not 
to block on having the flavors migrated until the M-release but I 
realise that has other undersiable consequences (ie high code maintenance).

Cheers,
Josh

[0] I found another one even: https://review.openstack.org/#/c/176172/

>
>> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev