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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp