Andreas and Neil,
Thank you so much for your help.
I was able to fix the issues thanks to your help.
Sangho
나의 iPhone에서 보냄
2018. 5. 11. 오후 7:19, Neil Jerram 작성:
>> On Fri, May 11, 2018 at 10:09 AM Andreas Scheuring
>> wrote:
>> So what you need to do first is to make a patch for networking
On Fri, May 11, 2018 at 10:09 AM Andreas Scheuring <
scheu...@linux.vnet.ibm.com> wrote:
> So what you need to do first is to make a patch for networking-onos that
> does ONLY the following
>
>
> replace all occurrences of
>
> * neutron.callbacks by neutron_lib.callbacks
> * neutron.plugins.ml2.d
So what you need to do first is to make a patch for networking-onos that does
ONLY the following
replace all occurrences of
* neutron.callbacks by neutron_lib.callbacks
* neutron.plugins.ml2.driver_api by neutron_lib.plugins.ml2.api
Push this patch for review. After that tests should succee
Andreas,
Thank you for your answer. Actually, I was able to make it use the correct
neutron API in my local tox tests, and all tests passed.
However, only in Zuul, I am still getting the following errors. :-(
Thank you,
Sangho
> 2018. 5. 9. 오후 4:04, Andreas Scheuring 작성:
>
> neutron.plugins
I just manually installed neutron in .tox folder (I am not sure if this is a
correct way to fix the problem) and run tox tests again.
And.. All tests passed.. as below..
But, I am not sure why Zuul tests fails as in my first email. :-(
Thank you,
Sangho
Tox tests success log in my local envir
neutron.plugins.ml2.driver_api got moved to neutron-lib. You probably need to
update the networking-onos code and fix all imports there and push the
changes...
---
Andreas Scheuring (andreas_s)
On 9. May 2018, at 10:00, Sangho Shin wrote:
Hello,
I am getting the following unit test error
Yes, let's move discussion to bug report.
On Fri, Jun 23, 2017 at 5:01 AM, Margin Hu wrote:
> Hi kevin,
>
> [ovs]
> bridge_mappings = physnet1:br-ex,physnet2:provision,physnet3:provider
> ovsdb_connection = tcp:10.53.16.12:6640
> local_ip = 10.53.32.12
> you can check the attachement, and more
Hi kevin,
[ovs]
bridge_mappings = physnet1:br-ex,physnet2:provision,physnet3:provider
ovsdb_connection = tcp:10.53.16.12:6640
local_ip = 10.53.32.12
you can check the attachement, and more logs can be found at
https://bugs.launchpad.net/neutron/+bug/1697243
On 6/23 16:43, Kevin Benton wrote:
Can you provide your ml2_conf.ini values you are using?
On Thu, Jun 22, 2017 at 7:06 AM, Margin Hu wrote:
> thanks.
>
> I met an issue , I configured three ovs bridge ( br-ex, provision,
> provider) in ml2_conf.ini but after I reboot the node , found only 2
> bridges flow table is normal , the
thanks.
I met an issue , I configured three ovs bridge ( br-ex, provision,
provider) in ml2_conf.ini but after I reboot the node , found only 2
bridges flow table is normal , the other one bridge's flow table is empty.
the bridge sometimes is "provision" , sometimes is "provider" , which
p
Rules to allow aren't setup until the port is wired and it calls the
functions like this:
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L602-L606
On Wed, Jun 21, 2017 at 4:49 PM, Margin Hu wrote:
> Hi Guys,
>
> I have a questi
Yes. The code will still require something to acknowledge that DHCP has
been wired for a port whether or not the agent extension is present.
On Fri, Mar 31, 2017 at 3:39 AM, Neil Jerram wrote:
> Thanks for the heads up, Kevin!
>
> Is this still necessary if a deployment disables the Neutron serv
Thanks for the heads up, Kevin!
Is this still necessary if a deployment disables the Neutron server's DHCP
scheduling, with
self._supported_extension_aliases.remove("dhcp_agent_scheduler")
?
Thanks,
Neil
On Fri, Mar 31, 2017 at 12:52 AM Kevin Benton wrote:
> Hi,
>
> Once [
RFE is at https://bugs.launchpad.net/neutron/+bug/1673142.
-Bob
On 3/13/17 2:37 PM, Robert Kukura wrote:
Hi Kevin,
I will file the RFE this week.
-Bob
On 3/13/17 2:05 PM, Kevin Benton wrote:
Hi,
At the PTG we briefly discussed a generic system for verifying that
the appropriate drivers
Hi Kevin,
I will file the RFE this week.
-Bob
On 3/13/17 2:05 PM, Kevin Benton wrote:
Hi,
At the PTG we briefly discussed a generic system for verifying that
the appropriate drivers are enforcing a particular user-requested
feature in ML2 (e.g. security groups, qos, etc).
Is someone plan
Hello,
In such case like You described, ports will be bound with openvswitch
mechanism driver because this agent will be found as alive on host. So
linuxbridge mechanism driver will do nothing for binding such ports.
--
Slawek Kaplonski
sla...@kaplonski.pl
W dniu 05.01.2017 04:51, zhi napisa
The mechanism drivers populate the vif details that tell nova how it's
supposed to setup the VM port. So the linux bridge driver tells it the port
type is linux bridge[1] and the OVS tells it that the type is OVS.
So if you have both loaded and ovs is running on the compute node. The
following ste
Hi, Kevin. If I load openvswitch and linuxbridge mechanism drivers in
neutron server, and running ovs-agent in compute nodes. What does
openvsitch mechanism driver do? What does linuxbridge mechanism do? I think
there must have some differences between the openvswitch and the
linuxbridge mechanism
Note that with the openvswitch and linuxbridge mechanism drivers, it will
be safe to have both loaded on the Neutron server at the same time since
each driver will only bind a port if it has an agent of that type running
on the host.
On Fri, Dec 30, 2016 at 1:24 PM, Sławek Kapłoński
wrote:
> Hel
Zhi,
Selection of driver is deployment dependent. You could run or more ML2
drivers simultaneous depending upon your deployment.
Hierarchical Port Binding (HPB) facilitates multi-segmented L2 networks
where the scope of the Segmentation ID is local to a given segment.
For example - if you want to
Hello,
I don't know what is hierarchical port binding but about mechanism
drivers, You should use this mechanism driver which L2 agent You are
using on compute/network nodes. If You have OVS L2 agent then You should
have enabled openvswitch mechanism driver.
In general both of those drivers are do
: "OpenStack Development Mailing List (not for usage questions)"
Date: 05/19/2016 05:34
Subject: Re: [openstack-dev] [Neutron][ML2][Routed Networks]
On Wed, May 18, 2016 at 5:24 AM, Hong Hui Xiao
wrote:
> I update [1] to auto delete dhcp port if there is no other ports. But
>
On Wed, 2016-05-18 at 15:29 -0600, Carl Baldwin wrote:
> On Wed, May 18, 2016 at 5:24 AM, Hong Hui Xiao wrote:
> > I update [1] to auto delete dhcp port if there is no other ports. But
> > after the dhcp port is deleted, the dhcp service is not usable. I can
>
> I think this is what I expect.
>
Stack Development Mailing List (not for usage questions)"
Date: 05/19/2016 05:34
Subject: Re: [openstack-dev] [Neutron][ML2][Routed Networks]
On Wed, May 18, 2016 at 5:24 AM, Hong Hui Xiao
wrote:
> I update [1] to auto delete dhcp port if there is no other ports. But
> after
On Wed, May 18, 2016 at 5:24 AM, Hong Hui Xiao wrote:
> I update [1] to auto delete dhcp port if there is no other ports. But
> after the dhcp port is deleted, the dhcp service is not usable. I can
I think this is what I expect.
> resume the dhcp service by adding another subnet, but I don't thi
g/#/c/317358
>
> HongHui Xiao(肖宏辉) PMP®
>
>
> From: Carl Baldwin
> To: OpenStack Development Mailing List
>
> Date: 05/18/2016 11:50
> Subject:Re: [openstack-dev] [Neutron][ML2][Routed Networks]
>
>
>
>
> On May 17, 2016 2:18 PM, "
when
deleting the existing one?
[1] https://review.openstack.org/#/c/317358
HongHui Xiao(肖宏辉) PMP®
From: Carl Baldwin
To: OpenStack Development Mailing List
Date: 05/18/2016 11:50
Subject: Re: [openstack-dev] [Neutron][ML2][Routed Networks]
On May 17, 2016 2:18 PM, "Ke
On May 17, 2016 2:18 PM, "Kevin Benton" wrote:
>
> >I kind of think it makes sense to require evacuating a segment of
its ports before deleting it.
>
> Ah, I left out an important assumption I was making. We also need to auto
delete the DHCP port as the segment is deleted. I was thinking this will
>I kind of think it makes sense to require evacuating a segment of its ports
before deleting it.
Ah, I left out an important assumption I was making. We also need to auto
delete the DHCP port as the segment is deleted. I was thinking this will be
basically be like the delete_network case where we
On Tue, May 17, 2016 at 10:56 AM, Kevin Benton wrote:
>>a) Deleting network's last segment will be prevented. Every network should
>> have at least one segment to let the port to bind.
>
> This seems a bit arbitrary to me. If a segment is limited to a small part of
> the datacenter, it being able
>a) Deleting network's last segment will be prevented. Every network should have
at least one segment to let the port to bind.
This seems a bit arbitrary to me. If a segment is limited to a small part
of the datacenter, it being able to bind for one section of the datacenter
and not the rest is no
Hi,
I create this patch [1] to allow multi-segmented routed provider networks
to grow and shrink over time, reviews are welcomed. I found these points
during working on the patch, and I think it is good to bring them out for
discussion.
a) Deleting network's last segment will be prevented. Eve
Hi folks,
I had a deep dive session with Bob (thx Bob).
We have a plan to solve the issue without any change of APIs or
manila driver reworks.
The process will look like the following:
1.) In case of multi-segment/hpb Manila creates a port like Ironic ML2
would do it [1]:
vif_type =
> On 09 Mar 2016, at 08:43, Sukhdev Kapur wrote:
>
> Hi Marc,
>
> I am driving the ironic-ml2 integration and introduced baremetal type for
> vmic_type.
Basically that’s my plan. So in my current implementation
I use the baremetal vnic_type [1] and add a binding profile [2].
> You can very
Hi Marc,
I am driving the ironic-ml2 integration and introduced baremetal type for
vmic_type.
You can very much use the same integration here - however, I am not
completely clear about your use case.
Do you want neutron/ML2 to plumb the network for Manila or do you want to
find out what VLAN (segm
> On 01 Mar 2016, at 06:22, Kevin Benton wrote:
>
> >This seems gross and backwards. It makes sense as a short term hack but
> >given that we have time to design this correctly I'd prefer to get this
> >information in a more straighforward way.
>
> Well it depends on what is happening here. I
For the moment Manila does following:
- creates Neutron port, consider "reserves" network info.
- then calls its own share driver that supports network handling and that
driver does binding on its backend.
- Neutron does not have info about real usage of a port and its info.
So, it is correct to s
>This seems gross and backwards. It makes sense as a short term hack but
given that we have time to design this correctly I'd prefer to get this
information in a more straighforward way.
Well it depends on what is happening here. If Manilla is wiring up a
specific VLAN for a port, that makes it pa
On 02/29/2016 04:38 PM, Kevin Benton wrote:
You're correct. Right now there is no way via the HTTP API to find which
segments a port is bound to.
This is something we can certainly consider adding, but it will need an
RFE so it wouldn't land until Newton at the earliest.
I believe Newton is the
Is Manila actually connecting (i.e. binding) something it controls to a
Neutron port, similar to how a Neutron L3 or DHCP agent connects a
network namespace to a port? Or does it just need to know the details
about a port bound for a VM (or a service)?
If the former, it should probably be usin
You're correct. Right now there is no way via the HTTP API to find which
segments a port is bound to.
This is something we can certainly consider adding, but it will need an RFE
so it wouldn't land until Newton at the earliest.
Have you considered writing an ML2 driver that just notifies Manilla o
Fixed neutron tag in the subject.
Marc wrote:
Hi Neutron team,
I am currently working on a feature for hierarchical port binding support
in
Manila [1] [2]. Just to give some context: In the current implementation
Manila
creates a neutron port but let it unbound (state DOWN). Therefore Man
Hi Gal,
I was hoping you will join us in yesterday's ML2 meeting to discuss
further. Anyhow, we would love your participation in this activity. Please
check the ether pad and see if you could join us in this sprint? If yes,
please sign up so that host can make appropriate arrangements.
Regardless
Hi Sukhdev,
The common sync framework is something i was also thinking about for some
time now.
I think its a very good idea and would love if i could participate in the
talks (and hopefully the implementation as well)
Thanks
Gal.
On Wed, Sep 9, 2015 at 9:46 AM, Sukhdev Kapur
wrote:
> Folks,
>
Hi Swami,
My fix for 1367391 will eventually eliminate the special DVRPortBinding
table, so would presumably eliminate this bug, but you are correct that
the current WIP patch (https://review.openstack.org/#/c/189410/) isn't
quite that far along yet. I'll look for an interim fix.
-Bob
On 6
On Thu, Apr 2, 2015 at 3:51 PM, Kevin Benton wrote:
> Whoops, wrong link in last email.
>
> https://etherpad.openstack.org/p/liberty-neutron-summit-topics
>
> On Thu, Apr 2, 2015 at 12:50 AM, Kevin Benton wrote:
>>
>> Coordinating communication between various backends for encapsulation
>> termin
Coordinating communication between various backends for encapsulation
termination is something that would be really nice to address in Liberty.
I've added it to the etherpad to bring it up at the summit.[1]
1. http://lists.openstack.org/pipermail/openstack-dev/2015-March/059961.html
On Tue, Mar
Whoops, wrong link in last email.
https://etherpad.openstack.org/p/liberty-neutron-summit-topics
On Thu, Apr 2, 2015 at 12:50 AM, Kevin Benton wrote:
> Coordinating communication between various backends for encapsulation
> termination is something that would be really nice to address in Libert
Hello,
I think that easiest way could be to have own mech_driver (AFAIK such
drivers are for such usage) to talk with external devices to "tell" them
what tunnels should it establish.
With change to tun_ip Henry propese l2_pop agent will be able to
establish tunnel with external device.
On Mon, M
hi henry,
thanks for this interesting idea. It would be interesting to think about
how external gateway could leverage the l2pop framework.
Currently l2pop sends its fdb messages once the status of the port is
modified. AFAIK, this status is only modified by agents which send
update_devce_up/down
>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
Hi henry,
It looks great and quite simple thanks to the work done by the ofagent team.
This kind of work might be used also for DVR which now support VLAN
networks [3].
I have some concerns about the patch submitted in [1], so let's review!
[3]https://review.openstack.org/#/c/129884/
On Wed, F
Your VM must be launched on the controller node then. In a multi-node setup
the controller will also act as a compute node unless you have disabled the
n-cpu service. The 'host' attribute is specifically to indicate where a
port is being used. It's not for anything else.
On Mon, Feb 2, 2015 at 1:1
Thanks Kevin for reply.
But 'host' attribute returns me the controller hostname and not compute
host name. I am having multi node setup, and I want to know compute host
where the VM get launch.
On Mon, Feb 2, 2015 at 2:19 PM, Kevin Benton wrote:
> ML2 makes the hostname available in the context
ML2 makes the hostname available in the context it passes to the drivers
via the 'host' attribute.[1] This is the only thing Neutron knows about the
compute node using the port.
1.
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/driver_api.py#L776
On Sun, Feb 1, 2015 at 10:11
Thank you! I managed to do it following your tip and the guide you sent.
2015-01-22 10:54 GMT-02:00 Jakub Libosvar :
> On 01/22/2015 01:00 PM, Ettore zugliani wrote:
> > I am implementing the precommit part of a mechanism driver (ml2) right
> > now i'm having problems with sqlalchemy.
> > I made
On 01/22/2015 01:00 PM, Ettore zugliani wrote:
> I am implementing the precommit part of a mechanism driver (ml2) right
> now i'm having problems with sqlalchemy.
> I made the class that uses the tables, but when the precommit is called
> an error pops up telling that the tables don't exists.
> T
Hi,
if you use a VLAN type driver, TOR switches should be configured in
trunk mode to allow VLAN specified in vlan_type section of
ml2_conf.ini.
vlan id range is defined in this section. Any tenant network will use
an id from this range, and it is totally independent from tenant id.
Some mechanism
gt;
> > -Original Message-
> > From: Mathieu Rohon [mailto:]
> > Sent: Wednesday, August 27, 2014 3:11 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support
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 han
essage-
> From: Mathieu Rohon [mailto:]
> Sent: Wednesday, August 27, 2014 3:11 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non
> promic mode adapters
>
> you probably sho
related to extension manager in ML2?
Thanks,
Irena
-Original Message-
From: Mathieu Rohon [mailto:]
Sent: Wednesday, August 27, 2014 3:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non
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, ov
> Please let me know if you would like to collaborate on this effort.
>>
>> BR,
>> Irena
>>
>> -Original Message-----
>> From: Andreas Scheuring [mailto:scheu...@linux.vnet.ibm.com]
>> Sent: Friday, August 22, 2014 11:16 AM
>> To: openstack-dev@lists.open
>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 irrel
On Wed, Aug 27, 2014 at 3:13 PM, Kevin Benton 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 ODL doesn't loo
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 ag
On Wed, Aug 27, 2014 at 12:42 PM, Kevin Benton 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 shim RESTful
>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 ke
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
Irena Berezovsky
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [neutron][ml2] Openvswitch agent support for non
promic mode adapters
Hi Irena,
thanks for your reply. Yes sure, collaboration would be great.
Do you already have a blueprint out there? Maybe we
4 11:16 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non
> promic mode adapters
>
> Thanks for your feedback.
>
> No, I do not yet have code for it. Just wanted to get a feeling if such a
> feature
-
From: Andreas Scheuring [mailto:scheu...@linux.vnet.ibm.com]
Sent: Friday, August 22, 2014 11:16 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non
promic mode adapters
Thanks for your feedback.
No, I do not yet have code for
Thanks for your feedback.
No, I do not yet have code for it. Just wanted to get a feeling if such
a feature would get acceptance in the community.
But if that helps I can sit down and start some prototyping while I'm
preparing a blueprint spec in parallel.
The main part of the implementation I
I think this sounds reasonable. Do you have code for this already, or are
you looking for a developer to help implement it?
On Thu, Aug 21, 2014 at 8:45 AM, Andreas Scheuring <
scheu...@linux.vnet.ibm.com> wrote:
> Hi,
> last week I started discussing an extension to the existing neutron
> openv
On Fri, Aug 15, 2014 at 2:26 PM, Kevin Benton 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 a
> driver/plu
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 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 revie
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 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 stringe
>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
the
On Thu, Aug 14, 2014 at 9:07 PM, Kyle Mestery 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 of the main Neu
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 networki
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 t
1 - 100 of 233 matches
Mail list logo
