[all][neutron][neutron-fwaas] FINAL CALL Maintainers needed

Sean Mooney smooney at redhat.com
Tue Jan 21 02:26:07 UTC 2020


On Mon, 2020-01-20 at 15:43 -0600, Eric K. Miller wrote:
> > Our community has mostly relied on commercial distribution vendors and
> > service providers to fill that role in the past. If enough of their customers say
> > it's a feature they're relying on, then employing developers who can help
> > keep it maintained is their raison d'ĂȘtre. This is how pretty much all free/libre
> > open source community software projects work.
> > --
> > Jeremy Stanley
> 
> Understood.  I thought there may be a way to crowd-fund something in case smaller operators had small budgets, needed
> some feature supported, but couldn't afford an entire employee with the small budget.
> 
> Maybe there are developer consultants interested in a gig to maintain something for a while.  Not sure where the best
> place to go for matching operators with consultants for this type of thing.
> 
> fwaas seems like such a necessity.  We would love to offer it, but it is unusable with DVR.  We just don't have the
> budget to hire someone specifically for development/support of this.
for  a lot of usecase security groups is sufficent and people do not need to enforce firewalls between
networks at neutron routers which is effectivly how fwaas worked. enfrocement via security groups on the ports attached
to the instance was sufficent. similarly for operators that have invested in an sdn solution they can porvide an out of
band policy enformce point. as a result in a normal openstack deployment fwaas became redundant.

there still usecase for this fwaas but less then you would think. much of the thing you migh typicaly do in an east west
direction or bettwen laywers in you applciation can be done using remote security groups instead of cidrs with security
groups. the gab that security groups did not fill easily was ironic and sriov however i belive some fo the heriacical
switch binding drives did support security impletend at the top of rack switch that could close that gap.

as a result FWaaS has become less deployed and less maintianed over time. the other issue as you noted is compatabliy
the fact that VPNaas FWaas and ovs dvr with ml2/ovs did not just work means its a hard sell. that is compounded by the
fact that none of the main sdn solutions supported it either.

any implematnion of FWaaS whould have provdied sevedor entroy point for neutron.agent.l2.firewall_drivers
https://github.com/openstack/neutron-fwaas/blob/master/setup.cfg#L45-L47 and neutron.agent.l3.firewall_drivers 
https://github.com/openstack/neutron-fwaas/blob/master/setup.cfg#L51-L53

but as you can see odl, ovn, mideonet, onos, contrail, dragonflow and calico do not implement support
https://github.com/openstack/networking-odl/blob/master/setup.cfg#L47-L66
https://github.com/openstack/networking-ovn/blob/master/setup.cfg#L51-L62
https://github.com/openstack/networking-midonet/blob/02e25cc65601add1d96b7150ed70403c3de4243b/setup.cfg#L58-L81
https://github.com/openstack/networking-onos/blob/master/setup.cfg#L40-L49
https://opendev.org/x/networking-opencontrail/src/branch/master/setup.cfg#L29-L32
https://github.com/openstack/dragonflow/blob/master/setup.cfg#L45-L121
https://github.com/openstack/networking-calico/blob/master/setup.cfg#L24-L30

networking-cisco provide an alternive fw api
https://opendev.org/x/networking-cisco/src/branch/master/setup.cfg#L97-L100
and arista support a security group api at the top or rack switch
https://opendev.org/x/networking-arista/src/branch/master/setup.cfg#L41

unless customers are asking vendors to provide FWaaS, in my experince it was never a telco prioity at least, vendor wont
have a buisness case to justify investment. That does not help those that do use FWaaS today but its a sad fact that
individuals and compaines need to choose wehre they spend there resouces carfully and FWaaS just never caught on enough
to remain relevent.

> 
> Eric
> 




More information about the openstack-discuss mailing list