yahoo-eng-team team mailing list archive

[Rohan <1153926@xxxxxxxxxxxxxxxxxx>]

** Also affects: tempest
   Importance: Undecided
       Status: New

** Changed in: tempest
     Assignee: (unassigned) => Rohan (kanaderohan)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1153926

Title:
  flavor show shouldn't read deleted flavors.

Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Compute (Nova):
  In Progress
Status in Python client library for Nova:
  In Progress
Status in Tempest:
  New

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1153926/+subscriptions