Race in instance_create with security_group_destroy

[Matthew Booth]

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.

[Markus Zoeller (markus_z) (mzoeller)]

As an info for potential assignees:
Matthew Booth tried to document this issue with this patch set: https://review.openstack.org/#/c/148273/