On 2013年08月17日 00:14, Vishvananda Ishaya wrote:
On Aug 15, 2013, at 5:58 PM, Melanie Witt <melw...@yahoo-inc.com> 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.
The API user is developer too, it shouldn't too difficult for them. I
prefer move the smarts into client
side. I'm open with two way. And I will comment in my patch for notice
reviewer vote for their flavor way before review my patch.
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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
