<div><span style="font-size: 15px;">Hi! ;)</span></div>
<p style="color: #A0A0A8;">On Thursday, 28 de May de 2015 at 9:03, Gal Sagie wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div dir="ltr"><div><div><div><div><div><div><div><div><div>Hello All,<br><br></div>The session talk was mainly about merging the Security Group API and the FWaaS API to the same one or to keep them separate,<br></div><div>Which i don't think we reached agreement (or did we? :) )<br></div></div></div></div></div></div></div></div></div></div></div></span></blockquote><div><br></div><div><span style="font-size: 15px;">I can’t tell either ;)</span></div><div> </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div dir="ltr"><div><div><div><div><div><div><div><div><br></div>I personally think (And few people approached us in the summit to express that they feel the same) that we need to allow the user the full set of features<br></div>to be able to configure both on the "perimeter" firewall and on the VM port, we can make the UI easier to apply a set of the features (similar to security groups for example)<br></div>on the VM ports but i feel merging the API's would make things easier in the long run (and then you can apply it either on the VM port or the router ports and of course<br></div><div>choose to apply only a simpler subset of the features) <br></div></div></div></div></div></div></div></div></span></blockquote><div><br></div><div><span style="font-size: 15px;">I guess, the complexity here lies in deprecating the security group API while offering a migration path, probably proxying security group calls to </span></div><div><span style="font-size: 15px;">FWaaS?, for full deprecation I guess you may need to coordinate with nova.</span></div><div><span style="font-size: 15px;"><br></span></div><div><span style="font-size: 15px;">FWaaS also lacks the ability to reference groups in rules, or is it capable of such thing? (ingress all from ‘sg-id’)</span></div><div><span style="font-size: 15px;"><br></span></div><div><span style="font-size: 15px;">Also you may want to make the FirewallDriver used for security groups part of FWaaS, and reuse/redesign the messaging mechanisms.</span></div><div><span style="font-size: 15px;"><br></span></div><div><span style="font-size: 15px;">I have mixed feelings about it, but I guess it could be a reasonable path so all the Firewall things are in one place, and not two.</span></div><div> </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div dir="ltr"><div><div><div><div><div></div><div><br></div>There are many security use cases that are detected and handled better on the Hypervisor / VM level which the current<br></div><div>security groups API doesn’t cover.<br></div><div><br></div>For the staying compatible with Amazon argument, i understand and think its important point, but there are already differences between different cloud providers (For example if you take Azure its "Security Group" features include actions) and i don’t think we need to hold off features and innovation because others aren’t doing it.<br></div></div></div></div></div></div></span></blockquote><div><br></div><div><span style="font-size: 15px;">I agree, that we shouldn’t stop innovation even if others aren’t doing it, otherwise we’re putting a ceiling on our capabilities, and we’re always going to be behind proprietary/closed source public clouds...</span></div><div> </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div dir="ltr"><div><div><div></div><br></div>We have already suggested and implemented (in review) easy way to extend new rule classes for security groups [1], [2]<br></div><div>And have implemented one use case for this [3], [4] (brute force prevention) (which we done a nice<br></div><div>research/analytic to create templates for common protocols login rates/retries and how to detected brute force probabilities -<br></div><div>can extend in private if anyone is interested but everything can be seen in the code) <br></div><div><br></div><div>I also feel that auditing visibility is important for security groups and i have a joint (with Roey Chen from VMware) API spec [5] <br>and reference implementation spec [6] to extend security groups auditing capabilities<br><br></div></div></div></div></span></blockquote><div><span style="font-size: 15px;">That came up into the “ovs sg ludicrous speed” talk, we may need auditing actions support in OvS at some point.</span></div><div> </div><div><span style="font-size: 15px;">Miguel Ángel Ajo,</span></div><div><br></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div dir="ltr"><div>None the less, would love to help and contribute code in any effort around this area and would like to see this move forward, i believe we have<br>an opportunity to give added value to the users with this.<br><br>Thanks<br>Gal.<br><br>[1] <a href="https://review.openstack.org/#/c/169784/">https://review.openstack.org/#/c/169784/</a><br>[2] <a href="https://review.openstack.org/#/c/154535/">https://review.openstack.org/#/c/154535/</a><br>[3] <a href="https://review.openstack.org/#/c/151247/">https://review.openstack.org/#/c/151247/</a><br>[4] <a href="https://review.openstack.org/#/c/184243/">https://review.openstack.org/#/c/184243/</a><br>[5] <a href="https://review.openstack.org/#/c/180078/">https://review.openstack.org/#/c/180078/</a><br>[6] <a href="https://review.openstack.org/#/c/180419/">https://review.openstack.org/#/c/180419/</a><br></div></div><div><br><div>On Thu, May 28, 2015 at 4:51 AM, Sridar Kandaswamy (skandasw) <span dir="ltr"><<a href="mailto:skandasw@cisco.com" target="_blank">skandasw@cisco.com</a>></span> wrote:<br><blockquote type="cite"><div>
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>Hi All:</div>
<div><br>
</div>
<div>Thanks German for articulating this – we did have this discussion on last Fri as well on the need to have more user inputs. FWaaS has been in a bit of a Catch22 situation with the experimental state. Regarding feature velocity – it has definitely been
frustrating and we also lost contributors along the journey due to their frustration with moving things forward making things worse.</div>
<div><br>
</div>
<div>Kilo has been interesting in that there are more new contributors, repo split and more in terms of vendor support has gone in than ever before. We hope that this will improve traction for the customers they represent as well. Adding more user inputs and
having a concerted conversation will definitely help. I echo Kyle and can certainly speak for all the current contributors in also helping out in any way possible to get this going. New Contributors are always welcome – Slawek & Vikram among the most recent
new contributors know this well.</div>
<div><br>
</div>
<div>Thanks</div>
<div><br>
</div>
<div>Sridar</div>
<div><br>
</div>
<span>
<div style="font-family:Calibri;font-size:11pt;text-align:left;color:black;BORDER-BOTTOM:medium none;BORDER-LEFT:medium none;PADDING-BOTTOM:0in;PADDING-LEFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df 1pt solid;BORDER-RIGHT:medium none;PADDING-TOP:3pt">
<span style="font-weight:bold">From: </span>Vikram Choudhary <<a href="mailto:vikschw@gmail.com" target="_blank">vikschw@gmail.com</a>><br>
<span style="font-weight:bold">Date: </span>Wednesday, May 27, 2015 at 5:54 PM<br>
<span style="font-weight:bold">To: </span>OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [neutron] [fwaas] - Collecting use cases for API improvements<br>
</div><div><div>
<div><br>
</div>
<div>
<div>
<div dir="ltr">Hi German,
<div><br>
</div>
<div>Thanks for the initiative. I am currently working for few of the FWaaS BP's proposed for Liberty and definitely would like to be a part of this effort. </div>
<div><br>
</div>
<div>BTW did you mean FWaaS IRC meeting to take up this discussion further?</div>
<div><br>
</div>
<div>Thanks</div>
<div>Vikram</div>
<div><br>
</div>
</div>
<div><br>
<div>On Thu, May 28, 2015 at 4:20 AM, Kyle Mestery <span dir="ltr">
<<a href="mailto:mestery@mestery.com" target="_blank">mestery@mestery.com</a>></span> wrote:<br><blockquote type="cite"><div>
<div dir="ltr">
<div>
<div><span>On Wed, May 27, 2015 at 5:36 PM, Eichberger, German
<span dir="ltr"><<a href="mailto:german.eichberger@hp.com" target="_blank">german.eichberger@hp.com</a>></span> wrote:<br><blockquote type="cite"><div>
All,<br>
<br>
<br>
During the FWaaS session in Vancouver [1] it became apparent that both the FWaaS API and the Security Groups API are lacking in functionality and the connection between the two is not well defined.<br>
<br>
<br>
For instance if a cloud user opens up all ports in the security groups they still can’t connect and might figure out days later that there is a second API (FWaaS) which prevents him from connecting to his service. This will probably make for a frustrating experience.<br>
<br>
<br>
Similarly, the operators I spoke to all said that the current FWaaS implementation isn’t going far enough and needs a lot of missing functionality added to fulfill their requirements on a Firewall implementation.<br>
<br>
<br>
With that backdrop I am proposing to take a step back and assemble a group of operators and users to collect use cases for the firewall service – both FWaaS and Security Groups based. I believe it is important at this juncture to really focus on the users and
less on technical limitations. I also think this reset is necessary to make a service which meets the needs of operators and users better.<br>
<br>
<br>
Once we have collected the use cases we can evaluate our current API’s and functionality and start making the necessary improvements to turn FWaaS into a service which covers most of the use cases and requirements.<br>
<br>
<br>
Please join me in this effort. We have set up an etherpad [2] to start collecting the use cases and will discuss them in an upcoming meeting.<br>
<br>
</div></blockquote><div><br>
</div>
</span>
<div>Thanks for sending this out German. I took home the same impressions that you did. Similar to what we did with the LBaaS project (to great success last summer), I think we should look at FWaaS API V2 with the new contributors coming on as equals and helping
to define the new operator focused API. My suggestion is we look at doing the work to lay the foundation during Liberty for a successful launch of this API during the Mxx cycle. I'm happy to step in here and guide the new group of contributors similar to what
we did for LBaaS.<br>
<br>
</div>
<div>Thanks,<br>
</div>
<div>Kyle<br>
</div>
<span>
<div> <br>
</div><blockquote type="cite"><div>
<br>
Thanks,<br>
<br>
German<br>
<br>
<br>
<br>
<br>
<br>
[1] <a href="https://etherpad.openstack.org/p/YVR-neutron-sg-fwaas-future-direction" target="_blank">
https://etherpad.openstack.org/p/YVR-neutron-sg-fwaas-future-direction</a><br>
<br>
[2] <a href="https://etherpad.openstack.org/p/fwaas_use_cases" target="_blank">https://etherpad.openstack.org/p/fwaas_use_cases</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
</div></blockquote></span></div>
<br>
</div>
</div>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
</div></blockquote></div>
<br>
</div>
</div>
</div>
</div></div></span>
</div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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></div></blockquote></div><br><br clear="all"><br>-- <br><div>Best Regards ,<br><br>The G. </div>
</div>
</div><div><div>__________________________________________________________________________</div><div>OpenStack Development Mailing List (not for usage questions)</div><div>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a></div><div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>