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