>That's just what I mean about horizontal, which is limited for some
features. For example, ports belonging to BSN driver and OVS driver can't
communicate with each other in the same tunnel network, neither does
security group across both sides.
There is no tunnel network in this case, just VLAN n
On Thu, Feb 26, 2015 at 10:50 AM, Kevin Benton wrote:
> You can horizontally split as well (if I understand what axis definitions
> you are using). The Big Switch driver for example will bind ports that
> belong to hypervisors running IVS while leaving the OVS driver to bind
> ports attached to h
You can horizontally split as well (if I understand what axis definitions
you are using). The Big Switch driver for example will bind ports that
belong to hypervisors running IVS while leaving the OVS driver to bind
ports attached to hypervisors running OVS.
I don't fully understand your comments
Oh, what you mean is vertical splitting, while I'm talking about horizontal
splitting.
I'm a little confused about why Neutron is designed so differently with
Nova and Cinder. In fact MD could be very simple, delegating nearly all
things out to agent. Remember Cinder volume manager? The real stora
In the cases I'm referring to, OVS handles the security groups and
vswitch. The other drivers handle fabric configuration for VLAN tagging to
the host and whatever other plumbing they want to do.
On Feb 25, 2015 5:30 PM, "loy wolfe" wrote:
>
>
> On Thu, Feb 26, 2015 at 3:51 AM, Kevin Benton wro
On Thu, Feb 26, 2015 at 3:51 AM, Kevin Benton 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 g
Yeah, it seems ML2 at the least should save you a lot of boilerplate.
On Feb 25, 2015 2:32 AM, "Russell Bryant" wrote:
> On 02/24/2015 05:38 PM, Kevin Benton wrote:
> > OVN implementing it's own control plane isn't a good reason to make it a
> > monolithic plugin. Many of the ML2 drivers are for
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.
There is a missing way to coordinate connectivity with tunnel networks
across drivers
On Wed, Feb 25, 2015 at 5:34 AM, Sukhdev Kapur
wrote:
> Folks,
>
> A great discussion. I am not expert at OVN, hence, want to ask a question.
> The answer may make a case that it should probably be a ML2 driver as
> oppose to monolithic plugin.
>
> Say a customer want to deploy an OVN based solu
On 02/24/2015 05:38 PM, Kevin Benton wrote:
> OVN implementing it's own control plane isn't a good reason to make it a
> monolithic plugin. Many of the ML2 drivers are for technologies with
> their own control plane.
>
> Going with the monolithic plugin only makes sense if you are certain
> that y
+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 (e
25, 2015 6:04 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN
Folks,
A great discussion. I am not expert at OVN, hence, want to ask a question. The
answer may make a case that it should probably be a ML2
Folks,
A great discussion. I am not expert at OVN, hence, want to ask a question.
The answer may make a case that it should probably be a ML2 driver as
oppose to monolithic plugin.
Say a customer want to deploy an OVN based solution and use HW devices from
one vendor for L2 and L3 (e.g. Arista o
I think we're speculating a lot about what would be best for OVN whereas we
should probably just expose pro and cons of ML2 drivers vs standalone
plugin (as I said earlier on indeed it does not necessarily imply
monolithic *)
I reckon the job of the Neutron community is to provide a full picture t
Kyle, What happened to the long-term potential goal of ML2 driver APIs
becoming neutron's core APIs? Do we really want to encourage new
monolithic plugins?
ML2 is not a control plane - its really just an integration point for
control planes. Although co-existence of multiple mechanism drivers
OVN implementing it's own control plane isn't a good reason to make it a
monolithic plugin. Many of the ML2 drivers are for technologies with their
own control plane.
Going with the monolithic plugin only makes sense if you are certain that
you never want interoperability with other technologies a
On Tue, Feb 24, 2015 at 3:19 AM, Salvatore Orlando
wrote:
> On 24 February 2015 at 01:34, Kyle Mestery wrote:
>
>> Russel and I have already merged the initial ML2 skeleton driver [1].
>>
> The thinking is that we can always revert to a non-ML2 driver if needed.
>>
>
> If nothing else an authori
17 matches
Mail list logo
