On Aug 15, 2013, at 5:58 PM, Melanie Witt <[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? It seems like getting around this would be as simple as: a. Create the port in neutron. b. Associate a security group with the port. c. Boot the instance with the port. In general I'm a fan of doing all of the network creation and volume creation in neutron and cinder before booting the instance. Unfortunately I think this is pretty unfriendly to our users. One possibility is to move the smarts into the client side (i.e. have it talk to neutron and cinder), but I think that alienates all of the people using openstack who are not using python-novaclient or python-openstack client. Since we are still supporting v2 this is a possibility for the v3 api, but if you can't do basic operations in v3 without talking to multiple services on the client side I think it will prevent a lot of people from using it. Its clear to me that autocreation needs to stick around for a while just to keep the apis usable. I can see the argument for pulling it from the v3 api, but it seems like at least the basics need to stick around for now. Vish _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
