> 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 __________________________________________________________________________ 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
