<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 16, 2013 at 10:28 AM, Melanie Witt <span dir="ltr"><<a href="mailto:melwitt@yahoo-inc.com" target="_blank">melwitt@yahoo-inc.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Aug 15, 2013, at 1:13 PM, Joe Gordon wrote:<br>
<br>
> +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.<br>
<br>
</div>Correct, it's unrelated to the ec2 api.<br>
<br>
We discussed briefly in the nova meeting today and there was consensus that removing the standalone associate/disassociate actions should happen.<br>
<br>
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.<br>

<br>
Would such a delay in associating with security groups be a problem?<br>
<div class="HOEnZb"><div class="h5"></div></div></blockquote><div><br></div><div>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.<br>
</div><div><br></div><div>+1 to removing the associate/disassociate actions though<br></div><div> <br></div><div>Chris<br></div><br></div></div></div>