On 2013?08?16? 14:34, Christopher Yeoh wrote:
On Fri, Aug 16, 2013 at 10:28 AM, Melanie Witt <[email protected] <mailto:[email protected]>> wrote:On Aug 15, 2013, at 1:13 PM, Joe Gordon wrote: > +1 from me as long as this wouldn't change anything for the EC2 API's security groups support, which I assume it won't. Correct, it's unrelated to the ec2 api. We discussed briefly in the nova meeting today and there was consensus that removing the standalone associate/disassociate actions should happen. Now the question is whether to keep the server create piece and not remove the extension entirely. The concern is about a delay in the newly provisioned instance being associated with the desired security groups. With the extension, the instance gets the desired security groups before the instance is active (I think). Without the extension, the client would receive the active instance and then call neutron to associate it with the desired security groups. Would such a delay in associating with security groups be a problem?I think we should keep the capability to set the security group on instance creation, so those who care about this sort of race condition can avoid if they want to.
I am working v3 network. I plan to only support create new instance with port id, didn't support with network id and fixed ip anymore. So that means user need create port from Neutron firstly, then pass the port id into the request of creating instance. If we think this is ok, user can associate the desired security groups when create port, and we can remove the securitygroup extension entirely.
+1 to removing the associate/disassociate actions though Chris _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
