yahoo-eng-team team mailing list archive

[Matthew Booth <mbooth@xxxxxxxxxx>]

Public bug reported:

There is a race in instance_create between fetching security groups
(returned by _security_group_get_by_names) and adding them to the
instance. We have no guarantee that they have not been deleted in the
meantime.

The result is currently that the SecurityGroupInstanceAssociation is
created, pointing to the deleted SecurityGroup. This is different to the
result of deleting the SecurityGroup afterwards, when both
SecurityGroupInstanceAssociation and SecurityGroup are marked deleted.
It is also different to the result of deleting the SecurityGroup before,
which is to raise an error.

While this intermediate state doesn't appear to cause an immediate
problem, I feel it would be likely to result in unexpected behaviour at
some point in the future, probably during a datamodel upgrade.

My preference would be to cause it to fail, as that feels intuitively to
me to be the most useful response to the end user (they have just
requested an instance with a security group, but the returned instance
already does not have that security group). However, either behaviour
would be correct IMO. I suspect the failure behaviour would be harder to
achieve in practice.

** Affects: nova
     Importance: Undecided
         Status: New

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

Title:
  Race in instance_create with security_group_destroy

Status in OpenStack Compute (Nova):
  New

Bug description:
  There is a race in instance_create between fetching security groups
  (returned by _security_group_get_by_names) and adding them to the
  instance. We have no guarantee that they have not been deleted in the
  meantime.

  The result is currently that the SecurityGroupInstanceAssociation is
  created, pointing to the deleted SecurityGroup. This is different to
  the result of deleting the SecurityGroup afterwards, when both
  SecurityGroupInstanceAssociation and SecurityGroup are marked deleted.
  It is also different to the result of deleting the SecurityGroup
  before, which is to raise an error.

  While this intermediate state doesn't appear to cause an immediate
  problem, I feel it would be likely to result in unexpected behaviour
  at some point in the future, probably during a datamodel upgrade.

  My preference would be to cause it to fail, as that feels intuitively
  to me to be the most useful response to the end user (they have just
  requested an instance with a security group, but the returned instance
  already does not have that security group). However, either behaviour
  would be correct IMO. I suspect the failure behaviour would be harder
  to achieve in practice.

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