[openstack-dev] [nova] Required data migrations in Kilo, need Turbo Hipster tests updated

Joshua Hesketh joshua.hesketh at rackspace.com
Thu Apr 23 05:41:05 UTC 2015

On 4/23/15 1:16 PM, Dan Smith wrote:
>> If I selected all the instance_type_id's from the system-metadata table
>> and used those uuid's to load the object with something like:
>>          instance = objects.Instance.get_by_uuid(
>>              context, instance_uuid,
>>              expected_attrs=['system_metadata', 'flavor'])
>> The tests would fail at that point when trying to read in the flavor as
>> json. http://paste.openstack.org/show/205158/
>> Basically without digging further it seems like I should be able to load
>> an instance by uuid regardless of the state of my flavor(s). Since this
>> fails it seems like there is something wrong with the flavor handling on
>> the objects.
> You should. The above is a reasonable result to get without the fix to
> ensure that we create instance_extra records for instances missing it.
> Do you still see the above with
>    https://review.openstack.org/#/c/176387/
> applied?

That change works on the dataset. However I was referring to the 
db/object api (which I have no real knowledge of) that it should be able 
to get_by_uuid unmigrated instances and in my case I got the traceback 
given in that paste. It's possible I'm just using the API incorrectly.

>> Another interesting thing is that migrate_flavor_data avoids migrating
>> instances that are in the middle of an operation. The snapshot of
>> databases we have include instances in this state. Since turbo-hipster
>> is just testing against a snapshot in time there is no way for those
>> instances to leave their working state and hence migrate_flavor_data can
>> never finish (every run will leave instances undone). This therefore
>> blocks the migrations from ever finishing.
> Ah, yeah, that's interesting, but I think it's a restriction we have to
> make for sanity.

Oh yes, we want that restriction, but a way around it for instances that 
may be stuck or just testing purposes could be useful.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150423/b915e928/attachment.html>

More information about the OpenStack-dev mailing list