| 2013-03-12 06:57:23 |
melanie witt |
description |
An instance type is created by:
return db.instance_type_create(context.get_admin_context(), kwargs)
which uses the read_deleted="no" from the admin context.
This means, as seen in nova/tests/test_instance_types.py:
def test_read_deleted_false_converting_flavorid(self):
"""
Ensure deleted instance types are not returned when not needed (for
example when creating a server and attempting to translate from
flavorid to instance_type_id.
"""
instance_types.create("instance_type1", 256, 1, 120, 100, "test1")
instance_types.destroy("instance_type1")
instance_types.create("instance_type1_redo", 256, 1, 120, 100, "test1")
instance_type = instance_types.get_instance_type_by_flavor_id(
"test1", read_deleted="no")
self.assertEqual("instance_type1_redo", instance_type["name"])
flavors with colliding ids can exist in the database.
From the test we see this looks intended, however it results in undesirable results if we consider the following scenario.
For 'show' in the flavors api, it uses read_deleted="yes". The reason for this is if a vm was created in the past with a now-deleted flavor, 'nova show' can still show the flavor name that was specified for that vm creation. The flavor name is retrieved using the flavor id stored with the instance.
Well, if there are colliding flavor ids in the database, the first of the duplicates will be picked, and it may not be the correct flavor for the vm.
This leads me to believe that maybe at flavor create time, colliding ids should not be allowed, i.e. use
return db.instance_type_create(context.get_admin_context(read_deleted="yes"), kwargs)
to prevent the possibility of colliding flavor ids. |
An instance type is created by:
return db.instance_type_create(context.get_admin_context(), kwargs)
which uses the read_deleted="no" from the admin context.
This means, as seen in nova/tests/test_instance_types.py:
def test_read_deleted_false_converting_flavorid(self):
"""
Ensure deleted instance types are not returned when not needed (for
example when creating a server and attempting to translate from
flavorid to instance_type_id.
"""
instance_types.create("instance_type1", 256, 1, 120, 100, "test1")
instance_types.destroy("instance_type1")
instance_types.create("instance_type1_redo", 256, 1, 120, 100, "test1")
instance_type = instance_types.get_instance_type_by_flavor_id(
"test1", read_deleted="no")
self.assertEqual("instance_type1_redo", instance_type["name"])
flavors with colliding ids can exist in the database.
From the test we see this looks intended, however it results in undesirable results if we consider the following scenario.
For 'show' in the flavors api, it uses read_deleted="yes". The reason for this is if a vm was created in the past with a now-deleted flavor, 'nova show' can still show the flavor name that was specified for that vm creation. The flavor name is retrieved using the flavor id stored with the instance.
Well, if there are colliding flavor ids in the database, the first of the duplicates will be picked, and it may not be the correct flavor for the vm.
This leads me to believe that maybe at flavor create time, colliding ids should not be allowed, i.e. use
return db.instance_type_create(context.get_admin_context(read_deleted="yes"),
kwargs)
to prevent the possibility of colliding flavor ids. |
|
