On Thu, Feb 26, 2015 at 3:51 AM, Kevin Benton <blak...@gmail.com> wrote:
> The fact that a system doesn't use a neutron agent is not a good > justification for monolithic vs driver. The VLAN drivers co-exist with OVS > just fine when using VLAN encapsulation even though some are agent-less. > so how about security group, and all other things which need coordination between vswitchs? > There is a missing way to coordinate connectivity with tunnel networks > across drivers, but that doesn't mean you can't run multiple drivers to > handle different types or just to provide additional features (auditing, > more access control, etc). > On Feb 25, 2015 2:04 AM, "loy wolfe" <loywo...@gmail.com> wrote: > >> +1 to separate monolithic OVN plugin >> >> The ML2 has been designed for co-existing of multiple heterogeneous >> backends, it works well for all agent solutions: OVS, Linux Bridge, and >> even ofagent. >> >> However, when things come with all kinds of agentless solutions, >> especially all kinds of SDN controller (except for Ryu-Lib style), >> Mechanism Driver became the new monolithic place despite the benefits of >> code reduction: MDs can't inter-operate neither between themselves nor >> with ovs/bridge agent L2pop, each MD has its own exclusive vxlan >> mapping/broadcasting solution. >> >> So my suggestion is that keep those "thin" MD(with agent) in ML2 >> framework (also inter-operate with native Neutron L3/service plugins), >> while all other "fat" MD(agentless) go with the old style of monolithic >> plugin, with all L2-L7 features tightly integrated. >> >> On Wed, Feb 25, 2015 at 9:25 AM, Amit Kumar Saha (amisaha) < >> amis...@cisco.com> wrote: >> >>> Hi, >>> >>> >>> >>> I am new to OpenStack (and am particularly interested in networking). I >>> am getting a bit confused by this discussion. Aren’t there already a few >>> monolithic plugins (that is what I could understand from reading the >>> Networking chapter of the OpenStack Cloud Administrator Guide. Table 7.3 >>> Available networking plugi-ins)? So how do we have interoperability between >>> those (or do we not intend to)? >>> >>> >>> >>> BTW, it is funny that the acronym ML can also be used for “monolithic” J >>> >>> >>> >>> Regards, >>> >>> Amit Saha >>> >>> Cisco, Bangalore >>> >>> >>> >>> >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
