<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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 class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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></blockquote><div><br></div><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><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
</blockquote></div><br></div></div>