Ports are bound in order of configured drivers so as long as the
OpenVswitch driver is put first in the list, it will bind the ports it can
and then ODL would bind the leftovers. [1][2] The only missing component is
that ODL doesn't look like it uses l2pop so establishing tunnels between
the OVS
On Wed, Aug 27, 2014 at 3:13 PM, Kevin Benton blak...@gmail.com wrote:
Ports are bound in order of configured drivers so as long as the
OpenVswitch driver is put first in the list, it will bind the ports it can
and then ODL would bind the leftovers. [1][2] The only missing component is
that
So why not agent based?
Maybe I have an experimental operating system that can't run python. Maybe
the RPC channel between compute nodes and Neutron doesn't satisfy certain
security criteria. Regardless of the reason, it doesn't matter because that
is an implementation detail that should be
l2pop is about l2 networks optimization with tunnel creation and arp
repsonder population (so this is
not only a overlays network optimization. For example ofagent now use
l2pop info for flat and vlan optimization [1]),
This optimization is orthogonal to several agent based mechanism
driver (lb,
It's more than just an optimization when it comes to overlay networks
though. It's the only way for agents to establish segment connectivity when
something like vxlan multicast discovery isn't possible. It shouldn't be
l2pop's responsibility for something like basic connectivity. That should
be
Forwarded from other thread discussing about incubator:
http://lists.openstack.org/pipermail/openstack-dev/2014-August/044135.html
Completely agree with this sentiment. Is there a crisp distinction between
a vendor plugin and an open source plugin though?
I think that opensource is not the
I think that opensource is not the only factor, it's about built-in vs.
3rd backend. Built-in must be opensource, but opensource is not necessarily
built-in. By my thought, current OVS and linuxbridge are built-in, but shim
RESTful proxy for all kinds of sdn controller should be 3rd, for they keep
On Wed, Aug 27, 2014 at 12:42 PM, Kevin Benton blak...@gmail.com wrote:
I think that opensource is not the only factor, it's about built-in
vs. 3rd backend. Built-in must be opensource, but opensource is not
necessarily built-in. By my thought, current OVS and linuxbridge are
built-in, but
On Fri, Aug 15, 2014 at 2:26 PM, Kevin Benton blak...@gmail.com wrote:
I definitely agree that reviewer time is wasted reviewing changes. However,
I don't think moving them to a different repo with different cores is going
to make them less brittle without some very strict guidelines about what
and
plugin repos
Oops – did I open a can of worms?
-Shiv
From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: Thursday, August 14, 2014 3:09 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on
I
I think the review time alone is a huge issue. Even worse, for the
most part, core reviewers are reviewing code for which they themselves
can't test because it requires proprietary hardware or software,
making the situation brittle at best. Having a separate git repository
which is gated by
On Thu, Aug 14, 2014 at 12:09:26PM +0200, Salvatore Orlando wrote:
I think there will soon be a discussion regarding what the appropriate
location for plugin and drivers should be.
My personal feeling is that Neutron has simply reached the tipping point
where the high number of drivers and
I definitely agree that reviewer time is wasted reviewing changes. However,
I don't think moving them to a different repo with different cores is going
to make them less brittle without some very strict guidelines about what a
driver/plugin is allowed to do.
For example, without neutron core
Hi,
I would like to add that it would be harder for the community to help
maintaining drivers.
such a work [1] wouldn't have occured with an out of tree ODL driver.
[1] https://review.openstack.org/#/c/96459/
On Wed, Aug 13, 2014 at 1:09 PM, Robert Kukura kuk...@noironetworks.com wrote:
One
On Thu, Aug 14, 2014 at 4:22 PM, Mathieu Rohon mathieu.ro...@gmail.com
wrote:
Hi,
I would like to add that it would be harder for the community to help
maintaining drivers.
such a work [1] wouldn't have occured with an out of tree ODL driver.
+1.
It's better to move all MD for none
I think there will soon be a discussion regarding what the appropriate
location for plugin and drivers should be.
My personal feeling is that Neutron has simply reached the tipping point
where the high number of drivers and plugins is causing unnecessary load
for the core team and frustration for
I also feel like the drivers/plugins are currently BEYOND a tipping
point, and are in fact dragging down velocity of the core project in
many ways. I'm working on a proposal for Kilo where we move all
drivers/plugins out of the main Neutron tree and into a separate git
repository under the
On Thu, Aug 14, 2014 at 9:07 PM, Kyle Mestery mest...@mestery.com wrote:
I also feel like the drivers/plugins are currently BEYOND a tipping
point, and are in fact dragging down velocity of the core project in
many ways. I'm working on a proposal for Kilo where we move all
drivers/plugins out
I also feel like the drivers/plugins are currently BEYOND a tipping
point, and are in fact dragging down velocity of the core project in
many ways.
Can you elaborate on the ways that they are slowing down the velocity? I
know they take up reviewer time, but are there other ways that you think
I've been working on this for OpenDaylight
https://github.com/dave-tucker/odl-neutron-drivers
This seems to work for me (tested Devstack w/ML2) but YMMV.
-- Dave
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
Hi,
The important thing to understand is how to integrate with neutron through
stevedore/entrypoints:
https://github.com/dave-tucker/odl-neutron-drivers/blob/master/setup.cfg#L32-L34
Cedric
On Wed, Aug 13, 2014 at 12:17 PM, Dave Tucker d...@dtucker.co.uk wrote:
I've been working on this
One thing to keep in mind is that the ML2 driver API does sometimes
change, requiring updates to drivers. Drivers that are in-tree get
updated along with the driver API change. Drivers that are out-of-tree
must be updated by the owner.
-Bob
On 8/13/14, 6:59 AM, ZZelle wrote:
Hi,
The
Howdy!
Rumor has it that it's easy to distribute ML2 mech drivers as out-of-tree
add-on modules.
Is this true? Has it been done? Where would one find an example?
Cheers!
-Luke
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
23 matches
Mail list logo
