Open Stack

On 2013年08月17日 00:14, Vishvananda Ishaya wrote:
> On Aug 15, 2013, at 5:58 PM, Melanie Witt <melwitt at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>