<div dir="ltr">Hi Phil, <div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 30, 2013 at 8:02 AM, Day, Phil <span dir="ltr"><<a href="mailto:philip.day@hp.com" target="_blank">philip.day@hp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">





<div lang="EN-GB" link="blue" vlink="purple">
<div>
<p class="">Hi Folks,<u></u><u></u></p>
<p class=""><u></u> <u></u></p>
<p class="">Currently the Nova SecGroup API extension doesn’t support the Quantum egress rules (as these aren’t available in the native Nova SecGroup implementation).     This can get quite confusing if there are egress rules defined in Quantum that
 then don’t show up in Nova (I know that’s partly the users problem for mixing their APIs) </p></div></div></blockquote><div><br></div><div style>I agree. By default the 'default' security group in quantum allows all egress traffic same as nova so hopefully most people should not notice this (as you pointed out only if using both API's). </div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div>
<p class="">– so I was wondering if as part of the V2 API work we could extend the scope of the Nova SecGroup extension to include the concept of egress rules, and then return a
 “Not Supported” error if someone tries to create one on a system configured for Nova Networking.</p></div></div></blockquote><div><br></div><div style>This seems easy enough to do but in my opinion but I don't think this would be moving us in the right direction. I see this more of a task of educating end users about the functionality differences. Security groups should be done in Quantum as part of networking. The proxy code was added to nova because the current nova api includes security groups attached to the instance. If egress filtering was added to nova,  horizon/python-novaclient would have to add support for this where it probably would have been easier to just switch over to quantum security groups that already implement this.  Lastly, the quantum security group api doesn't completely match up cleanly to the nova security group api (for example, quantum exposes ethertype). I would rather see efforts spent in moving away from proxing the security group info from nova to quantum to just talking to quantum. What do you think? </div>
<div style><br></div><div style>That said if someone wants to add this extension great. :)  . </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-GB" link="blue" vlink="purple"><div><p class=""><u></u><u></u></p>
<p class=""><u></u> <u></u></p>
<p class="">What do people think, and how do ideas  like this get tagged against the V3 work (new blueprint, add to an existing one, etc)</p></div></div></blockquote><div style>I'm curious about this too. I'm hoping that in the nova v3 api we can remove security groups and networking from an instance and leaving all the information in quantum for the client to query directly. </div>
<div style> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple">
<div><p class=""><span class=""><font color="#888888"><u></u><u></u></font></span></p><span class=""><font color="#888888">
<p class=""><u></u> <u></u></p>
<p class="">Phil</p></font></span></div></div></blockquote><div style>Best, </div><div style><br></div><div style>Aaron </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>