Open Stack

On 2013?08?16? 14:34, Christopher Yeoh wrote:
>
> On Fri, Aug 16, 2013 at 10:28 AM, Melanie Witt <melwitt at yahoo-inc.com 
> <mailto: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?
>
>
> 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130816/df2f6103/attachment-0001.html>