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.
Cheers,
Josh
--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
