rie...@linux.vnet.ibm.com>
wrote:
> On 9/1/2016 12:05 PM, Suresh Vinapamula wrote:
>
>> On 8/31/2016 4:17 PM, Dan Smith wrote:
>>
>> Thanks Dan for your response. While I do run that before I start
>> my
>> move to liberty, what I see is
On 8/31/2016 4:17 PM, Dan Smith wrote:
Thanks Dan for your response. While I do run that before I start my
move to liberty, what I see is that it doesn't seem to flavor migrate
meta data for the VMs that are spawned after controller upgrade from
juno to kilo and before all computes upgraded from
Hi,
What is the typical protocol/guideline followed in the community to handle
deprecated fields during upgrade procedure?
Should the fields be removed by the user/admin before upgrade is initiated
or would the -manage db_sync, or migrate_flavor_data etc... or any
other command take care of
Sure, will file a bug with my observations.
On Wed, Aug 31, 2016 at 2:17 PM, Dan Smith wrote:
> > Thanks Dan for your response. While I do run that before I start my
> > move to liberty, what I see is that it doesn't seem to flavor migrate
> > meta data for the VMs that are
>> While migrate_flavor_data seem to flavor migrate meta data of the VMs
>> that were spawned before upgrade procedure, it doesn't seem to flavor
>> migrate for the VMs that were spawned during the upgrade procedure more
>> specifically after openstack controller upgrade and before compute
>>
Hi,
I am upgrading from Juno to Kilo and from that to Liberty.
I understand I need to nova-manage db migrate_flavor_data before upgrading
from Kilo to Liberty to let VMs that were spawned while the system was in
Juno to flavor migrate to Kilo.
Depending on the number of computes, complete