To me it's not so much out vs in (even though it plays an important part
in my thinking process), but it's a matter of promoting the 'right' long
term driver, because once people get their hands on them, it's difficult
to get them to move away.
Obviously, the stateless driver is out there and anyone after the
adequate due diligence is entitled to deploy it if they want to, but I
simply don't think it's right for the Neutron community to endorse it as
a viable long-term solution.
That said, this has been a great and educational chat for me and I have
appreciated the input. For now, I am going to mark this provisionally as
won't fix.
** Changed in: neutron
Status: Triaged => Won't Fix
** Changed in: neutron
Assignee: Rodolfo Alonso (rodolfo-alonso-hernandez) => (unassigned)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1531205
Title:
[RFE] ovs openflow security group driver
Status in neutron:
Won't Fix
Bug description:
when using standard kernel ovs it may be desirable for performance reasons to
use an ovs based security group driver.
When using ovs with dpdk it is not possible to use a kernel(ip tables) based
security driver.
one effort leveraging the newly added kernel connection tracker support in
ovs is tracked by
https://bugs.launchpad.net/neutron/+bug/1461000
ovs integration with conntrack will be supported in the upcoming ovs 2.5
release.
At present the proposed 2.5 release will only support conntrack with the
linux kernel dataplane,
as such a conntrack based openflow security group driver can not currently be
used with dpdk,windows or bsd
dataplanes.
to support the security group api with ovs without conntrack we would like
summit the learn action based openflow firewall driver
current hosted in networking-ovs-dpdk for inclusion in neutron.
https://github.com/openstack/networking-ovs-dpdk/blob/master/networking_ovs_dpdk/agent/ovs_dpdk_firewall.py
The networking-ovs-dpdk OVSFirewallDriver was originally developed for
liberty with support for ipv4 only.
subsequently support for ipv6 and and multicast have been developed(should be
completed this week).
As this security group driver utilities reflective learn actions instead of
connection tracking it can in theory support
all ovs datapath. the driver has been developed and tested with ovs 2.4 and
both the linux kernel and dpdk datapaths.
Note that while both the iptables and connection tracking approach provide a
stateful security group implementation
the lean action based ovs firewall driver uses a stateless design.
If both the conntrack and learn based security group drivers are accepted for
the mitaka cycle the deployed
will then be able to select which driver to use based on the requirement of
there system.
if the system has ovs 2.5+ and the kernel datapath and a kernel with
conntrack support the conntrack based security driver can be used.
if the system has ovs 2.4+ with the userspace netdev
datapath(bsd/dpdk) or kernel datapath (linux and possible windows)
the learn based security group driver can be used.
if the system has ovs <=2.3 and is using the linux kernel datapath the
current iptables security group driver can be used.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1531205/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : [email protected]
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
