Re: [openstack-dev] [neutron][stadium][networking] Seeking proposals for non-voting Stadium projects in Neutron check queue

Hi Miguel, all, The initiative is very welcome and will help make it more efficient to develop in stadium projects. legacy-tempest-dsvm-networking-bgpvpn-bagpipe would be a candidate, for networking-bgpvpn and networking-bagpipe (it covers API and scenario tests for the BGPVPN API

Re: [openstack-dev] [networking-odl][networking-bgpvpn][ceilometer] all requirement updates are currently blocked

Mathew, networking-odl has now been removed from the requirements of networking-bgpvpn [1], on master, so networking-odl could be removed from requirements. This is not the case on stable branches, though. -Thomas [1] https://review.openstack.org/#/c/599422/ On 05/09/2018 17:03, Matthew

Re: [openstack-dev] [stable][networking-bgpvpn][infra] missing networking-odl repository / tox-siblings & tox_install.sh

Hi Előd, Thanks for looking into that. Summary: - we  removed networking-odl from required-projects of networking-bgpvpn because of a history of networking-odl changes breaking functional tests in networking-bgvpn (since networking-bgpvpn master declares networking-odl in requirements.txt ,

Re: [openstack-dev] [requirements][horizon][neutron] plugins depending on services

Hi Monty, Thanks for bringing this up. Having run into the topic for a few combination of deps, I'll certainly agree that we need something better than what we currently have. I don't feel that I've enough perspective on the whole system and practices to give a strong opinion on what we

Re: [openstack-dev] [requirements][horizon][neutron] plugins depending on services

On 25/04/2018 18:40, Jeremy Stanley wrote: This came up again a few days ago for sahara-dashboard. We talked through some obvious alternatives to keep its master branch from depending on an unreleased state of horizon and the situation today is that plugin developers have been relying on

Re: [openstack-dev] [kolla][neutron][requirements][pbr]Use git+https line in requirements.txt break the pip install

As I understand, this is due to a not-yet-completed transition in networking-odl after stopping the use of the tools/tox_install.sh and relying on the tox-sibling CI role instead. I'm not able to explain the difference between the two "pip install" run variants that you see, though. For the

Re: [openstack-dev] [Neutron] Propose Slawek Kaplonski for Neutron core

+1 ! -Thomas Miguel Lavalle, 2017-11-29 13:21: > Hi Neutron Team, > > I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core. > Slawek has been an active contributor to the project since the Mitaka > cycle. He has been instrumental in the development of the QoS > capabilities in

Re: [openstack-dev] [kolla] [neutron] PTG cross-platform meetup possibility

Vikram Hosakote (vhosakot), 2017-09-07 15:38: > Would there be any interest in meeting with the Kolla team at the PTG > to discuss neutron’s > integration with containers and Kubernetes especially about the new > networking > technologies like VPP, fd.io, OpenDaylight, OVS-DPDK, OVN, service >

[openstack-dev] [neutron] - FFE for networking-bagpipe, support for MPLS-over-GRE

Hi PTL/all, I would like to request an exception for inclusion in Pike, of MPLS/GRE support in networking-bagpipe. The feature consists in allowing the use of a new OVS tunnel option added in the very recently released OVS 2.8. The code is ready, the only piece preventing the merge is that the

Re: [openstack-dev] [neutron] - FFE requests for Pike

Hi Kevin, Am I right to assume this applies to stadium projects as well ? (since they now are all under cycle-with-milestones) -Thomas Kevin Benton, 2017-07-30 23:52: > Hi all, > > If you have any Neutron-related FFE requests for Pike please send an > email to the dev list with [neutron] in

Re: [openstack-dev] [networking-bagpipe] exabgp dependency

Hi James, FYI, exabgp 4.0.0 has been released and this release can be package to satisfy networking-bagpipe needs. A request for adding exabgp as a proper OpenStack requirement is in flight: https://review.openstack.org/#/c/467068 Best, -Thomas

Re: [openstack-dev] [networking-bagpipe] exabgp dependency

Hi James, Indeed, we have moved from shipping a fork of an old exabgp in bagpipe-bgp (a.k.a."vendoring", i.e. baaad...) to using upstream, but we have dependencies on exabgp development branch. I've been in touch with ExaBGP main author, who plans to release exabgp 4 from master "soon". The

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

Hi Cathy, Cathy Zhang: I will tentatively set the meeting time to UTC 1700 ~ UTC 1800 Tuesday. Hope this time is good for all people who have interest and like to contribute to this work. We plan to start the first meeting on May 17. I would be happy to participate, but I'm unlikely to be

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

Doug : [snip] I get your point. This would indeed correctly model intermediate releases. But since no other project in Openstack depends on networking-bgpvpn, what is the value of forcing a release of the project synched at the end of a cycle ? It raises your chances of having your project

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

Hi Irena, Irena Berezovsky : > I would like to second Kevin. This can be done in a similar way as ML2 Plugin passed plugin_context > to ML2 Extension Drivers: https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/driver_api.py#L910. Yes, this would be similar and could indeed

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

Hi Ihar, Ihar Hrachyshka : Miguel Angel Ajo : Do you have a rough idea of what operations you may need to do? Right now, what bagpipe driver for networking-bgpvpn needs to interact with is: - int_br OVSBridge (read-only) - tun_br OVSBridge (add patch port, add flows) - patch_int_ofport port

[openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

Hi everyone, (TL;DR: we would like an L2 agent extension to be able to call methods on the agent class, e.g. OVSAgent) In the networking-bgpvpn project, we need the reference driver to interact with the ML2 openvswitch agent with new RPCs to allow exchanging information with the BGP VPN

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

Kevin, Miguel, I agree that (4) is what makes most sense. (more below) Miguel Angel Ajo : Do you have a rough idea of what operations you may need to do? Right now, what bagpipe driver for networking-bgpvpn needs to interact with is: - int_br OVSBridge (read-only) - tun_br OVSBridge (add

Re: [openstack-dev] talk proposal for Tokyo Summit: Interconnecting Neutron and BGP-based operator VPNs

Hello everyone, My apologies for this french-speaking message that *not* intended to this list, but to a french speaking mailing-list with a close name... The idea was to encourage people to look at our Interconnecting Neutron and BGP-based operator VPNs where we'll discuss the Neutron

[openstack-dev] talk proposal for Tokyo Summit: Interconnecting Neutron and BGP-based operator VPNs

Salut à tous, On propose un talk Interconnecting Neutron and BGP-based operator VPNs pour le summit de Tokyo. Ca aidera si on a des votes, merci d'avance ! ** https://www.openstack.org/summit/tokyo-2015/vote-for-speakers/Presentation/5747

Re: [openstack-dev] [Neutron][bgpvpn] IRC meetings on BGP VPN interconnection API

Hi Paul, all, Yes, it's good to have a discussion on BGP VPN and edge VPN proposals during the VPNaaS meeting. At least Mathieu and I will participate to see how we can help. To avoid confusion we think it's good to keep separate the discussion on the details of the work around the

Re: [openstack-dev] [Neutron][bgpvpn] IRC meetings on BGP VPN interconnection API

Hi, We confirm this meeting for tomorrow Tuesday 2nd @15:00 UTC on #openstack-meeting-alt . We'll discuss tomorrow what we want to do for future IRC meetings (day, time, periodicity, etc.). (Everyone is encouraged to also follow the VPNaaS meeting that will follow) Best, -Thomas

[openstack-dev] [Neutron][bgpvpn] IRC meetings on BGP VPN interconnection API

Hi everyone, As a follow-up to discussions last week on a BGP VPN interconnection API and the work started with the people already involved, we are going to hold IRC meetings to discuss how to progress the different pieces of work, in particular on the API itself [1] and its

Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal

Hi, keshav...@hp.com : If this BaGpipe BGP does not support MPLS data plane driver, what is advantage of this BGP from current. Just to avoid any misunderstanding: Bagpipe BGP **does** support an MPLS dataplane for IPVPN today. For E-VPN, bagpipe could support an MPLS dataplane with a new

Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal

Hi all, We've just released our implementation of BGP VPN extensions (called 'BaGPipe'), under a opensource license : https://github.com/Orange-OpenSource/bagpipe-bgp It reuses some code from ExaBGP, but with a dedicated engine for VPN instance creation through a rest API, and a modular