Re: [openstack-dev] [neutron][stable] Stable Core Team Update

[Thomas Morin]

+1 !

-Thomas

On 10/2/18 5:41 PM, Miguel Lavalle wrote:

Hi Stable Team,

I want to nominate Bernard Cafarrelli as a stable core reviewer for 
Neutron and related projects. Bernard has been increasing the number 
of stable reviews he is doing for the project [1]. Besides that, he is 
a stable maintainer downstream for his employer (Red Hat), so he can 
bring that valuable experience to the Neutron stable team.


Thanks and regards

Miguel

[1] 
https://review.openstack.org/#/q/(project:openstack/neutron+OR+openstack/networking-sfc+OR+project:openstack/networking-ovn)++branch:%255Estable/.*+reviewedby:%22Bernard+Cafarelli+%253Cbcafarel%2540redhat.com%253E%22


__
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

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

[Thomas Morin]

Thomas Morin, 2018-09-03 13:31:
> Matthew Thode, 2018-08-31 19:52:
> > 
> > If networking-odl is not meant to be used as a library I'd
> > recommend
> > it's removal from networking-bgpvpn (it's test-requirements.txt
> > file).
> 
> We can work at removing this historical driver from networking-
> bgpvpn. Since a v2 driver (hosted in networking-odl) has been
> existing for a long time, we possibly can do that without waiting.
> Just need to think about the best way to do it.

Realizing that we've had a warning announcing deprecation and
future removal for the last release [1], I've pushed [2] to remove the
ODL driver from master without waiting.

Please comment there as needed.

-Thomas

[1] 
https://github.com/openstack/networking-bgpvpn/commit/ffee38097709dd4091fb8709a70cf6c361ed60ee#diff-88cc53515016b9f865a830b216c8e564
[2] https://review.openstack.org/599422


> > Once that is done networking-odl can be removed from global-
> > requirements
> > and we won't be blocked anymore.
> > 
> > As a side note, fungi noticed that when you branched you are still
> > installing ceilometer from master.  Also, the ceilometer team
> > doesnt wish it to be used as a library either (like networking-odl
> > doesn't wish to be used as a library).
> > 
> > ___
> > __
> > _
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
> > bs
> > cribe
> > 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:unsubs
> cribe
> 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

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

[Thomas Morin]

Hi Mathew,

Matthew Thode, 2018-08-31 19:52:
> The requirements project has a co-installability test for the various
> projects, networking-odl being included.
> 
> Because of the way the dependancy on ceilometer is done it is
> blocking all reviews and updates to the requirements project.

(also blocking reviews for networking-bgpvpn)

> 
http://logs.openstack.org/96/594496/2/check/requirements-integration/8378cd8/job-output.txt.gz#_2018-08-31_22_54_49_357505
> 
> If networking-odl is not meant to be used as a library I'd recommend
> it's removal from networking-bgpvpn (it's test-requirements.txt
> file).

Historically, the driver allowing the use of networking-bgpvpn with the
ODL SDN controller was in the networking-bgpvpn project ; this is why
we have this dependency (the driver using some ODL utility code found
in the networking-odl project).

We can work at removing this historical driver from networking-bgpvpn.
Since a v2 driver (hosted in networking-odl) has been existing for a
long time, we possibly can do that without waiting. Just need to think
about the best way to do it.

ODL team, what do you think ?

In the meantime, to unbreak the CI for networking-bgpvpn, I'm pushing
[1], which puts an upper bound (< 13) on the dependency on networking-
odl to avoid drawing version 13 of networking-odl which introduces the
requirement on ceilometer.

-Thomas

[1] https://review.openstack.org/#/c/599310/2/test-requirements.txt


> Once that is done networking-odl can be removed from global-
> requirements
> and we won't be blocked anymore.
> 
> As a side note, fungi noticed that when you branched you are still
> installing ceilometer from master.  Also, the ceilometer team
> doesnt wish it to be used as a library either (like networking-odl
> doesn't wish to be used as a library).
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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

Re: [openstack-dev] [requirements][neutron] Depending on pypi versions

[Thomas Morin]

Hi Gary,
Seehttp://lists.openstack.org/pipermail/openstack-dev/2018-March/128311
.html
> Note that thanks to the tox-siblings feature, we really continue to>
install neutron and horizon from git - and not use the versions in> the
global-requirements constraints file,
Gary Kotton, 2018-03-19 11:25:
> Hi,
> The change https://github.com/openstack/requirements/commit/35653e8c5
> 044bff1059f50a82b6065176eea has created some issues with
> decomposed neutron plugins. Let me try and give an example to
> explain.
> Say for example a patch landed in neutron master that exposed feature
> X. Now if a decomposed plugin wants to consume this it will fail as
> the decomposed plugin will pull in the latest tag.
> Does this mean for each new feature that we wish to consume we will
> need to update neutron tags?
> Please advise.
> Thanks
> Gary
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I think it is worth adding a comment in (test-)requirements.txt that
the OpenStack CI is overriding the version and uses git.

-Thomas

__
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

Re: [openstack-dev] [requirements][kolla] new requirements change on upper-constraints.txt break horizon & neutron

[Thomas Morin]

Hi Andreas,
In the documentation for networking-bgpvpn, we suggest to install these
packages with "pip install -c https://git.openstack.org/cgit/openstack/
requirements/plain/upper-constraints.txtt networking-bgpvpn=8.0.0" .In
many cases this can work well enough for people wanting to try this
component on top of an existing installation, assuming they follow a
few extra steps explained in the rest of the doc.
Adding networing-bgpvpn to upper-constraints.txt will break this way of
doing things.
-Thomas
Andreas Jaeger, 2018-03-16 11:53:
> On 2018-03-16 11:42, Thomas Morin wrote:
> > This is related to the topic in "[horizon][neutron]
> > tools/tox_install
> > changes - breakage with constraints".
> > 
> > proposes to remove these projects from upper-constraints (for a
> > different reason)
> > https://review.openstack.org/#/c/552865
> > <https://review.openstack.org/#/c/552865/> that adds other projects
> > to
> > global-requirements, explicitly postpone their addition to
> > upper-constraints to a later step
> > 
> > Perhaps neutron and horizon should be removed from upper-
> > constraints for
> > now ? (ie restore https://review.openstack.org/#/c/553030 ?)
> 
> Yes, that would be one option. but I like to understand whether that
> would be a temporary solution - or the end solution.
> 
> Jeffrey, how exactly are you installing neutron? From git? From
> tarballs?
> 
> Andreas

__
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

Re: [openstack-dev] [Neutron] Dublin PTG Summary

[Thomas Morin]

Miguel Lavalle, 2018-03-12 13:45:
> * Ruijing Guo proposed to support VLAN transparency in Neutron OVS
> agent.
> 
> [...]   - While on this topic, the conversation temporarily forked to
> the use of registers instead of ovsdb port tags in L2 agent br-int
> and possibly remove br-tun. Thomas Morin committed to draft a RFE for
> this.

Here is the RFE: https://bugs.launchpad.net/neutron/+bug/1756296

It does not yet cover a possible following step where br-tun would be
removed.

Cheers,

-Thomas


> __
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

Re: [openstack-dev] [requirements][kolla] new requirements change on upper-constraints.txt break horizon & neutron

[Thomas Morin]

This is related to the topic in "[horizon][neutron] tools/tox_install
changes - breakage with constraints".
proposes to remove these projects from upper-constraints (for a
different reason)https://review.openstack.org/#/c/552865 that adds
other projects to global-requirements, explicitly postpone their
addition to upper-constraints to a later step
Perhaps neutron and horizon should be removed from upper-constraints
for now ? (ie restore  https://review.openstack.org/#/c/553030  ?)
Jeffrey Zhang, 2018-03-16 18:31:
> recently, a new patch is merged[0]. It adds neutron and horizon
> itself into
> upper-constraints.txt. But this will break installing horizon and
> neutron with
> upper-constraints.txt. 
> 
> Now it breaks the kolla's master branch patch. And have to remove the
> "horizon"
> and "neutron" in the files. check[1][2]. 
> 
> The easier way to re-produce this is
> 
>   git clone https://github.com/openstack/horizon.git
>   cd horizon
>   pip install -c https://git.openstack.org/cgit/openstack/requirement
> s/plain/upper-constraints.txt .
> 
> So the question is, is this expected? if so, what's the correct way
> to install horizon develop
> branch with upper-constraints.txt file?
> 
> 
> [0] https://review.openstack.org/#/c/550475/
> [1] https://review.openstack.org/#/c/549456/4/docker/neutron/neutron-
> base/Dockerfile.j2
> [2] https://review.openstack.org/#/c/549456/4/docker/horizon/Dockerfi
> le.j2
> 
> 
> -- 
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-Thomas

__
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

Re: [openstack-dev] [horizon][neutron] tools/tox_install changes - breakage with constraints

[Thomas Morin]

Hi Doug,

Doug Hellmann, 2018-03-14 23:42:
> We keep doing lots of infra-related work to make it "easy" to do
>  when it comes to
> managing dependencies.  There are three ways to address the issue
> with horizon and neutron, and none of them involve adding features
> to pbr.
> 
> 1. Things that are being used like libraries need to release like
>libraries. Real releases. With appropriate version numbers. So
>that other things that depend on them can express valid
> dependencies.
> 
> 2. Extract the relevant code into libraries and release *those*.
> 
> 3. Things that are not stable enough to be treated as a library
>shouldn't be used that way. Move the things that use the
> application
>code as library code back into the repo with the thing that they
>are tied to but that we don't want to (or can't) treat like a
>library.

What about the case where there is co-development of features across
repos ? One specific case I have in mind is the Neutron stadium where
we sometimes have features in neutron repo that are worked on as a pre-
requisite for things that will be done in a neutron-* or networking-*
project. Another is a case for instance where we need to add in project
X a tempest test to validate the resolution of a bug for which the fix
actually happened in project B (and where B is not a library).

My intuition is that it is not illegitimate to expect this kind of
development workflow to be feasible; but at the same time I read your
suggestion above as meaning that it belongs to the real of "things we
shouldn't be doing in the first place".  The only way I can reconcile
the two would be to conclude we should collapse all the module in
neutron-*/networking-* into neutron, but doing that would have quite a
lot of side effects (yes, this is an understatement).

-Thomas


__
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

Re: [openstack-dev] [horizon][neutron] tools/tox_install changes - breakage with constraints

[Thomas Morin]

Hi Andreas, all,
> Note that thanks to the tox-siblings feature, we really continue to
> install neutron and horizon from git - and not use the versions in
> the global-requirements constraints file.

This addresses my main concern, which was that by removing
tools/tox_install.sh we would end up not pulling master from git.

The fact that we do keep pulling from git wasn't explicit AFAIK in any
of the commit messages of the changes I had to look at to understand
what was being modified.

I concur with Akihiro's comment, and would go slightly beyond that:
ideally the solution chosen would not only technical work, but would
reduce the ahah-there-is-magic-behind-the-scene effect, which is a pain
I believe for many: people new to the community face a steeper learning
curve, people inside the community need to spend time adjust, and infra
folks end up having to document or explain more.  In this precise
case,  the magic behind the scene (ie. the tox-siblings role) may lead
to confusion for packagers (why our CI tests as valid is not what
appears
in requirements.txt) and perhaps people working in external communities
(e.g. [1]).
Best,

-Thomas

[1] http://docs.opnfv.org/en/latest/submodules/releng-xci/docs/xci-over
view.html#xci-overview

Andreas Jaeger, 2018-03-14 20:46:__
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

Re: [openstack-dev] [neutron] Stepping down from core

[Thomas Morin]

Sad to hear. You brought a lot to the community in particular in
helping the Neutron Stadium take shape.

Thank you for that and all the rest!

Hoping you'll keep contributing as actively as possible,

-Thomas


Armando M., 2017-12-15 11:01:
> Hi neutrinos,
> 
> To some of you this email may not come as a surprise.
> 
> During the past few months my upstream community engagements have
> been more and more sporadic. While I tried hard to stay committed and
> fulfill my core responsibilities I feel like I failed to retain the
> level of quality and consistency that I would have liked ever since I
> stepped down from being the Neutron PTL back at the end of Ocata.
> 
> I stated many times when talking to other core developers that being
> core is a duty rather than a privilege, and I personally feel like
> it's way overdue for me to recognize on the mailing list that it's
> the time that I state officially my intention to step down due to
> other commitments.
> 
> This does not mean that I will disappear tomorrow. I'll continue to
> be on neutron IRC channels, support the neutron team, being the
> release liasion for Queens, participate at meetings, and be open to
> providing feedback to anyone who thinks my opinion is still valuable,
> especially when dealing with the neutron quirks for which I might be
> (git) blamed :)
> 
> Cheers,
> Armando
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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-dev] [neutron] New core on networking-bgpvpn

[Thomas Morin]

Hi everyone,

Let me welcome Édouard Thuleau (doude) as a new core on
networking-bgpvpn!

Édouard has been following and contributing from the early days, in
particular on the framework and on the API client. He knows the project
well and has done multiple reviews. He also knows about the questions
related to drivers, having written the driver for OpenContrail.  

Cheers,

-Thomas





































































__
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-dev] Re : [Neutron] Denver Team Dinner

[Thomas Morin]

+1

-Thomas


Takashi Yamamoto, 2017-09-13 03:05:
> +1
> 
> On Wed, Sep 13, 2017 at 2:56 AM, IWAMOTO Toshihiro
>  wrote:
> > +1
> > thanks for organizing!
> > 
> > On Wed, 13 Sep 2017 14:18:45 +0900,
> > Brian Haley wrote:
> > > 
> > > +1
> > > 
> > > On 09/12/2017 10:44 PM, Ihar Hrachyshka wrote:
> > > > +1
> > > > 
> > > > On Tue, Sep 12, 2017 at 9:44 PM, Kevin Benton  > > > > wrote:
> > > > > +1
> > > > > 
> > > > > On Tue, Sep 12, 2017 at 8:50 PM, Sławek Kapłoński  > > > > lonski.pl>
> > > > > wrote:
> > > > > > 
> > > > > > +1
> > > > > > 
> > > > > > —
> > > > > > Best regards
> > > > > > Slawek Kaplonski
> > > > > > sla...@kaplonski.pl
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > Wiadomość napisana przez Miguel Lavalle  > > > > > > com> w dniu
> > > > > > > 12.09.2017, o godz. 17:23:
> > > > > > > 
> > > > > > > Dear Neutrinos,
> > > > > > > 
> > > > > > > Our social event will take place on Thursday September
> > > > > > > 12th at 7:30pm.
> > > > > > > The venue is going to be https://www.famousdaves.com/Denv
> > > > > > > er-Stapleton. It is
> > > > > > > located 0.4 miles from the Renaissance Hotel, which
> > > > > > > translates to an easy 9
> > > > > > > minutes walk.
> > > > > > > 
> > > > > > > I have a reservation for a group of 30 people under my
> > > > > > > name. Please
> > > > > > > respond to this message with your attendance confirmation
> > > > > > > by Wednesday
> > > > > > > night, so I can get a more accurate head count.
> > > > > > > 
> > > > > > > Looking forward to see y'all Thursday night
> > > > > > > 
> > > > > > > Best regards
> > > > > > > 
> > > > > > > Miguel
> > > > > > > 
> > > > > > > _
> > > > > > > _
> > > > > > > OpenStack Development Mailing List (not for usage
> > > > > > > questions)
> > > > > > > Unsubscribe:
> > > > > > > openstack-dev-requ...@lists.openstack.org?subject:unsubsc
> > > > > > > ribe
> > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/opens
> > > > > > > tack-dev
> > > > > > 
> > > > > > 
> > > > > > ___
> > > > > > ___
> > > > > > OpenStack Development Mailing List (not for usage
> > > > > > questions)
> > > > > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subj
> > > > > > ect:unsubscribe
> > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/opensta
> > > > > > ck-dev
> > > > > > 
> > > > > 
> > > > > 
> > > > > _
> > > > > _
> > > > > OpenStack Development Mailing List (not for usage questions)
> > > > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subjec
> > > > > t: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-d
> > > > ev
> > > > 
> > > 
> > > 
> > > _
> > > _
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:un
> > > subscribe
> > > 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:unsu
> > bscribe
> > 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:unsubs
> cribe
> 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

Re: [openstack-dev] [neutron][horizon][fwaas][vpnaas] fwaas/vpnaas dashboard split out

[Thomas Morin]

Kevin Benton :
> Some context here: 
http://lists.openstack.org/pipermail/openstack-dev/2017-April/115200.html

>

Thanks, I had missed this one.

So, what I gather is that the only drawback noted for "(b) dashboard 
code in individual project" is "Requires extra efforts to support 
neutron and horizon codes in a single repository for testing and 
translation supports. Each project needs to explore the way.".   While I 
won't disagree, my question would be the following: since we have 
something that works (except dashboard translation, which we haven't 
explored), should we move to the model agreed on for new work (given 
that there is also overhead in creating and maintaining a new repo) ?


Best,

-Thomas


On Wed, Jun 21, 2017 at 2:33 AM, Thomas Morin <thomas.mo...@orange.com 
<mailto:thomas.mo...@orange.com>> wrote:


Hi Akihiro,

While I understand the motivation to move these dashboards from
openstack/horizon, what is the reason to prefer a distinct repo
for the dashboard rather than hosting it in the main repo of these
projects ?

(networking-bgpvpn has had a dashboard for some time already, it
is hosted under networking-bgpvpn/bgpvpn_dashboard and we haven't
heard about any drawback)

Thanks,

-Thomas



Akihiro Motoki :

Hi neutron and horizon teams (especially fwaas and vpnaas folks),

As we discussed so far, I prepared separate git repositories for FWaaS
and VPNaaS dashboards.
http://git.openstack.org/cgit/openstack/neutron-fwaas-dashboard/
<http://git.openstack.org/cgit/openstack/neutron-fwaas-dashboard/>
http://git.openstack.org/cgit/openstack/neutron-vpnaas-dashboard/
<http://git.openstack.org/cgit/openstack/neutron-vpnaas-dashboard/>

All new features will be implemented in the new repositories, for
example, FWaaS v2 support.
The initial core members consist of neutron-fwaas/vpnaas-core
(respectively) + horizon-core.

There are several things to do to complete the split out.
I gathered a list of work items at the etherpad and we will track the
progress here.
https://etherpad.openstack.org/p/horizon-fwaas-vpnaas-splitout
<https://etherpad.openstack.org/p/horizon-fwaas-vpnaas-splitout>
If you are interested in helping the efforts, sign up on the etherpad
or contact me.

I would like to release the initial release which is compatible with
the current horizon
FWaaS/VPNaaS dashboard (with no new features).
I hope we can release it around R-8 week (Jul 3) or R-7 (Jul 10).

It also will be good examples for neutron stadium/related projects
which are interested in
adding dashboard support. AFAIK, networking-sfc, tap-as-a-service are
interested in it.

Thanks,
Akihiro

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<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

Re: [openstack-dev] [neutron][horizon][fwaas][vpnaas] fwaas/vpnaas dashboard split out

[Thomas Morin]

Hi Akihiro,

While I understand the motivation to move these dashboards from 
openstack/horizon, what is the reason to prefer a distinct repo for the 
dashboard rather than hosting it in the main repo of these projects ?


(networking-bgpvpn has had a dashboard for some time already, it is 
hosted under networking-bgpvpn/bgpvpn_dashboard and we haven't heard 
about any drawback)


Thanks,

-Thomas



Akihiro Motoki :

Hi neutron and horizon teams (especially fwaas and vpnaas folks),

As we discussed so far, I prepared separate git repositories for FWaaS
and VPNaaS dashboards.
http://git.openstack.org/cgit/openstack/neutron-fwaas-dashboard/
http://git.openstack.org/cgit/openstack/neutron-vpnaas-dashboard/

All new features will be implemented in the new repositories, for
example, FWaaS v2 support.
The initial core members consist of neutron-fwaas/vpnaas-core
(respectively) + horizon-core.

There are several things to do to complete the split out.
I gathered a list of work items at the etherpad and we will track the
progress here.
https://etherpad.openstack.org/p/horizon-fwaas-vpnaas-splitout
If you are interested in helping the efforts, sign up on the etherpad
or contact me.

I would like to release the initial release which is compatible with
the current horizon
FWaaS/VPNaaS dashboard (with no new features).
I hope we can release it around R-8 week (Jul 3) or R-7 (Jul 10).

It also will be good examples for neutron stadium/related projects
which are interested in
adding dashboard support. AFAIK, networking-sfc, tap-as-a-service are
interested in it.

Thanks,
Akihiro

__
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-dev] [neutron] br-int to use registers instead of ovsdb tags (was: Re: Enable arp_responder without l2pop)

[Thomas Morin]

Wed Feb 22 2017 11:13:18 GMT-0500 (EST), Anil Venkata:


While relevant, I think this is not possible until br-int allows to 
match the network a packet belongs to (the ovsdb port tags don't let 
you do that until the packet leaves br-int with a NORMAL action).


Ajo has told me yesterday that the OVS firewall driver uses
registers precisely to do that. Making this generic (and not
specific to the OVS firewall driver) would be a prerequisite
before you can add ARP responder rules in br-int.

[...] Spoke to Ajo on this. He said we can follow above suggestion i.e 
do the same what firewall driver is doing in br-int, or wait till OVS 
flow extension is implemented(but this will take time as lack of 
resources)


I think using registers instead of ovsdb port tags should be seen as a 
common pre-requisite for both ARP responder in br-int and doing the OVS 
flow extension work.
So waiting for resource on the later should not be seen as the problem.. 
although you still need some resource to use register in br-int...


-Thomas
__
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-dev] [infra] merging code from a github repo to an openstack existing repo: how ?

[Thomas Morin]

Hi,

A bit of context to make my question clearer: 
openstack/networking-bagpipe relies on bagpipe-bgp which is not an 
openstack project although done by the same people, and we would see a 
significant benefit in moving the code from github to openstack. This 
post does not relate to licence/CLA questions (all clear AFAIK, licence 
is Apache, all contributions by people who are also Openstack 
contributors). It does not relate to code style or lib dependencies 
either (there are a few things to adapt, which we have identified and 
mostly covered already).


The target would be: have the content of github's bagpipe-bgp repo 
become a sub directory of the networking-bagpipe repo, and then tweak 
setup.cfg/tox.ini so that this subdirectory becomes packaged and tested.


The question is:  how to achieve that without squashing/losing all git 
history (and without pushing one gerrit change per existing commit in 
the current history) ?


Would the following work...?
- in the github repo: prepare a 'move_to_openstack' branch  where all 
repo content is moved in a 'bagpipe_bgp' subdir

- in networking-bagpipe repo:
   * create a 'welcome_bagpipe_bgp' branch
   * have a manual step where someone (infra team ?) adds the github 
repo as a remote and merges the remote 'move_to_openstack' branch into 
the 'welcome_bagpipe_bgp' local branch (without squashing).
   * in this 'welcome_bagpipe_bgp' branch do whatever is needed in 
terms of setup.cfg/requirements.txt/tox.ini ...
   * when everything is ready, merge the 'welcome_bagpipe_bgp' branch 
into master

- (in the gitub repo: replace the content with an explanation message)

(If the above does not work, what other possibility ?)

-Thomas

[1]  https://github.com/Orange-OpenSource/bagpipe-bgp


__
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

Re: [openstack-dev] [neutron] Enable arp_responder without l2pop

[Thomas Morin]

Hi Anil,

Tue Feb 21 2017 22:47:46 GMT-0500 (EST), Anil Venkata:

Currently arp_resonder can enabled only if l2pop is enabled.

Can we have arp_responder feature enabled without l2pop(i.e Remove the 
dependency between arp_responder and l2_pop)?




I agree that it would be useful.
networking-bgpvpn ovs/bagpipe driver is relying on arp_responder, and 
hence currently draws this dependency on l2pop (not an issue I find, but 
still an artefact rather than a design decision).



Also setup arp_responder on OVS integration bridge(and not on br-tun)?



While relevant, I think this is not possible until br-int allows to 
match the network a packet belongs to (the ovsdb port tags don't let you 
do that until the packet leaves br-int with a NORMAL action).
Ajo has told me yesterday that the OVS firewall driver uses registers 
precisely to do that. Making this generic (and not specific to the OVS 
firewall driver) would be a prerequisite before you can add ARP 
responder rules in br-int.


I think this question (of where to put the ARP responder rules) also 
relates to https://review.openstack.org/#/c/320439/ .


-Thomas

__
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

Re: [openstack-dev] [neutron] - approximate schedule for PTG / networking-bgpvpn

[Thomas Morin]

Hi everyone,

I propose to meet and discuss networking-bgpvpn tomorrow (Wed) after the 
Neutron session.
Current and future contributors to the service plugin or to drivers are 
welcome!


-Thomas



Sat Feb 18 2017 15:42:24 GMT-0500 (EST), Kevin Benton:

Hi All,


Here is a rough outline of the order in which I want to cover the 
items: https://etherpad.openstack.org/p/neutron-ptg-pike-final



I've also put together a calendar that has the meeting times as well 
as a few relevant cross project sessions and our team dinner/photo.


I suggest watching the calendar for changes since we will need to make 
adjustments as we go.


ICAL: 
https://calendar.google.com/calendar/ical/khbmhi1mhtthrmgv2gnejtul3o%40group.calendar.google.com/public/basic.ics


HTML page: 
https://calendar.google.com/calendar/embed?src=khbmhi1mhtthrmgv2gnejtul3o%40group.calendar.google.com=America/New_York



If you notice any conflicts or missing items, reply right away so I 
can get it fixed.


Cheers,
Kevin Benton


__
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

Re: [openstack-dev] [neutron] - approximate schedule for PTG

[Thomas Morin]

Hi Kevin, all,

A few things:
- I think it would be useful to discuss the work for L2 extension ovs 
flow management [1] on Thursday aft.

- I'm ready to expose where we are on n8g-bgpvpn on Friday morning
- If time allows, it would be great to take some time to 
discuss/encourage the adoption of push notification by stadium projects 
(such as networking-bgpvpn and networking-sfc, possibly others). Perhaps 
a bootstrap overview of the things that need to be done to adopt this 
model would help.


-Thomas

[1] https://review.openstack.org/#/c/320439/


Sat Feb 18 2017 15:42:24 GMT-0500 (EST), Kevin Benton:

Hi All,


Here is a rough outline of the order in which I want to cover the 
items: https://etherpad.openstack.org/p/neutron-ptg-pike-final



I've also put together a calendar that has the meeting times as well 
as a few relevant cross project sessions and our team dinner/photo.


I suggest watching the calendar for changes since we will need to make 
adjustments as we go.


ICAL: 
https://calendar.google.com/calendar/ical/khbmhi1mhtthrmgv2gnejtul3o%40group.calendar.google.com/public/basic.ics


HTML page: 
https://calendar.google.com/calendar/embed?src=khbmhi1mhtthrmgv2gnejtul3o%40group.calendar.google.com=America/New_York



If you notice any conflicts or missing items, reply right away so I 
can get it fixed.


Cheers,
Kevin Benton


__
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

Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

[Thomas Morin]

+1 !

-Thomas

Fri Feb 17 2017 20:18:41 GMT+0100 (CET), Kevin Benton:

Hi all,

I'm organizing a Neutron social event for Thursday evening in Atlanta 
somewhere near the venue for dinner/drinks. If you're interested, 
please reply to this email with a "+1" so I can get a general count 
for a reservation.


Cheers,
Kevin Benton


__
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

Re: [openstack-dev] [neutron] neutron-classifier (CCF) at the PTG

[Thomas Morin]

Hi,

I have no opinion on where/when this should happen, but will be 
interested to participate.


-Thomas

Tue Feb 14 2017 15:39:22 GMT+0100 (CET), Duarte Cardoso, Igor:


Hi neutron,

Me and David would like to discuss the Common Classification Framework 
(CCF) (current approach based on openstack/neutron-classifier) at the 
PTG but we aren’t sure if the main session is the appropriate forum 
for that or if we should only have a meeting with the interested 
people and a few Neutron cores or PTL (to discuss if and how this work 
could be brought closer to Neutron itself).


I appreciate your feedback, thanks!

Best regards,

Igor.



__
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

Re: [openstack-dev] [neutron] [stadium] subprojects on independent release cycle

[Thomas Morin]

Hi Armando,

As far as networking-bgpvpn and networking-bagpipe are concerned, the 
plan is to do like we've been doing for the past 2 releases, which is to 
cut a branch and make a release not too far after Openstack.
The date of March 10th looks reasonable as a target, and we'll stick to 
that.


Best,

-Thomas


On 2 February 2017 at 16:09, Armando M. > wrote:


   Hi neutrinos,

   I have put a number of patches in the merge queue for a few
   sub-projects. We currently have a number of these that are on an
   independent release schedule. In particular:

 * networking-bagpipe
 * networking-bgpvpn
 * networking-midonet
 * networking-odl
 * networking-sfc

   Please make sure that between now and March 10th [1], you work to
   prepare at least one ocata release that works with neutron's [2] and
   cut a stable branch before than. That would incredibly help
   consumers who are interested in assembling these bits together and
   start testing ocata as soon as it's out.

   Your collaboration is much appreciated.

   Many thanks,
   Armando


Hi neutrinos,

I did not hear anything back from the liaisons of the above mentioned 
project over the past few days. Can you clarify your plans for cutting 
an Ocata release?


Thanks,
Armando


   [1] https://releases.openstack.org/ocata/schedule.html
   
   [2] https://review.openstack.org/#/c/428474/
   





__
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

Re: [openstack-dev] [neutron]Do we need to rfe to implement active-active router?

[Thomas Morin]

Hi,

What would active-active exactly be in DVR mode ?

-Thomas

Le 16/11/2016 à 16:42, huangdenghui a écrit :

hi
Currently, neutron support DVR router and legacy router. For high 
availability, there is HA router in reference implementation of legacy 
mode and DVR  mode. I am considering whether is active-active router 
needed in both mode?





__
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-dev] [neutron][n8n-bgpvpn] meeting on BGP VPN in Barcelona: Fri 1pm

[Thomas Morin]

Hi folks,

For those who are interested to discuss networking-bgpvpn Ocata, I 
propose that we meet tomorrow at 1pm in the Contributors' meetup room 
(CCIB 114).


Among the things we can discuss:
- pending things related to neutron stadium
-   ^ in particular, CI testing
- what API evolutions to prioritize for Ocata (E-VPN, static routes, 
Port associations)
- discuss the idea of supporting multiple drivers simultaneously (e.g. 
per compute) and how

- update on bagpipe reference driver
- update on other drivers
- packaging work and related questions
- things happening in OPNFV/SDNVPN
-...

See you tomorrow, or at the Neutron social tonight...

-Thomas


__
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

Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

[Thomas Morin]

Hi Miguel,

I plan to attend!

-Thomas

Fri Oct 14 2016 20:30:57 GMT+0200 (CEST), Miguel Lavalle:

Dear Neutrinos,

I am organizing a social event for the team on Thursday 27th at 19:30. 
After doing some Google research, I am proposing Raco de la Vila, 
which is located in Poblenou: 
http://www.racodelavila.com/en/index.htm. The menu is here: 
http://www.racodelavila.com/en/carta-racodelavila.htm


It is easy to get there by subway from the Summit venue: 
https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people 
under 'Neutron' or "Miguel Lavalle". Please confirm your attendance so 
we can get a final count.


Here's some reviews: 
https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html


Cheers

Miguel


__
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

Re: [openstack-dev] [neutron] Social at the summit

[Thomas Morin]

+1 !

Mon Apr 25 2016 10:55:33 GMT-0500 (CDT), Kyle Mestery:

Ihar, Henry and I were talking and we thought Thursday night makes sense for a 
Neutron social in Austin. If others agree, reply on this thread and we'll find 
a place.

Thanks!
Kyle

__
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

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

[Thomas Morin]

Hi Neil,

Neil Jerram :

[snip]
I've since realised that my initial statement above wasn't quite right.
In fact, because networking-calico uses Neutron interfaces that are
pretty stable (ML2 mech driver, DHCP interface driver, etc.) we have
found it manageable until now to develop a single (master) branch of the
networking-calico code that works with all of the OpenStack releases
(Icehouse..Liberty) that we have tested with; and I'd like if possible
to continue doing that.


This makes a lot of sense.
I believe this can be very relevant for many ML2 mechanism drivers, in 
particular.


It leads me to believe that branch names in a subproject may not be the 
right way to indicate what Openstack branch, or branch_es_ now that you 
put this forward, are targeted.


Back to my humble suggestion in my previous email... Having an 
"openstack-target.txt" in a project listing the Openstack branch(es) 
that this project branch targets could possibly help.




On reflection, therefore, I believe it's correct that networking-calico
development has been happening, and continues to happen, on its master
branch, and I hope that we won't ever need stable branches *for the
reason of working with different OpenStack releases* (e.g. if it become
too difficult to target many OpenStack releases from a single branch).



This scenario would be covered by having multiple branches, each with a 
different content in "openstack-target.txt".


But, well, I don't know if this idea of mine can be relevant.

-Thomas



__
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

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

[Thomas Morin]

Hi Thierry,

Thanks for you answers, more below.

Thierry Carrez :

Thomas Morin wrote:

The starting point for this post is a specific Neutron sub-project
(networking-bgpvpn) but I believe the issues raised are shared with
other neutron stadium project and possibly relevant beyond Neutron, to
projects tagged release-independent in general.

In the context of the networking-bgpvpn project, we have a few unsolved
issues related to branches, more specifically about which branches we
can create to host active development to make our subprojet (a Neutron
service plugin) work with the last Openstack release and to backport it
with to earlier releases.

Here are precisely the assumptions that we've made, largely based on the
fact that the project is tagged 'release-independent' (meaning
"completely bypass the 6-month cycle and release independently" [1]):
a) that we can make a release targeting Liberty much later than the
release date of Liberty
b) that we could make releases more frequent than the 6-month cycle ;
not only bugfix releases but also feature releases
c) that the idea of a release-independent project being backported to
work with past Openstack releases is acceptable (of course, without
requiring any change in release-managed projects, something largely
possible in many cases for projects such as a Neutron service plugin or
an ML2 driver)

So we have three models. The release:independent model is for projects
that don't follow the common development cycle, and therefore won't make
a "liberty" release. The release:cycle-with-milestones model is the
traditional "one release at the end of the cycle" model, and the
release:cycle-with-intermediary model is an hybrid where you follow the
development cycle (and make an end-of-cycle release) but can still make
intermediary, featureful releases as necessary.

The difference between the two groups is the concept of per-cycle
branches (the stable/liberty branch which is used to maintain backports
following the stable branch policy). Projects following the
release:independent model should not have a stable/liberty branch, since
they didn't formally do a liberty release. Those independent projects
that have a stable/liberty branch are actually all
release:cycle-with-intermediary projects that ignore their true nature.

Looking at your specific case, it appears you could adopt the
release:cycle-with-intermediary model, since you want to maintain a
branch mapped to a given release.


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 ?


(also, there is maybe an implication of release milestones and code 
freezes that may be overkill for some big tent projects, in particular 
when they are young)




The main issue is your (a) point, especially the "much later" point.
Liberty is in the past now, so making
"liberty" releases now that we are deep in the Mitaka cycle is a bit
weird.


"weird" I don't know: isn't it consistent with "release independently" ?


When are you likely to start shipping your liberty branch ?


We're mostly done and we target November.



Maybe we need a new model to care for such downstream projects when they
can't release in relative sync with the projects they track.


I would think so.

The reason is that we want to still do the majority of the work in one 
branch, to avoid the overhead of cherry-picking between branches a large 
amount of changes (e.g. if we had been working in a liberty branch since 
September, all this work would have had to be cherry-picked to our 
master -- and vice-versa: working in master would have meant 
cherry-picking everything in the liberty branch).




Note that we aren't the only big tent project having this kind of
expectations (e.g. [3]).

The rest of this email follows from these assumptions.

To do (a) and (c) we need separate branches in which to do active work.
We have understood clearly that given the contract around 'stable/*'
branches, the branches in which to do this active work cannot be named
'stable/*'.

Where we are today:
- we do active development, planning a liberty release soon, on our
'master' branch
- we have a 'backport/kilo' and a 'backport/juno' branches in which we
plan to make the necessary changes to adapt with Neutron kilo and juno;
these branches were created by Neutron core devs for us [5], based on
the common understanding that choosing 'stable/*' branch names for
branches with active development would be a huge no no
[...]

So we had that discussion at the last design summit: how should we name
those branches that track a given release cycle but do not necessarily
follow the common stable branch policy. My initial idea was to reserve
usage of the stable/* name to things following stable branch policy. But
that creates a number

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

[Thomas Morin]

Hi everyone,

The starting point for this post is a specific Neutron sub-project 
(networking-bgpvpn) but I believe the issues raised are shared with 
other neutron stadium project and possibly relevant beyond Neutron, to 
projects tagged release-independent in general.


In the context of the networking-bgpvpn project, we have a few unsolved 
issues related to branches, more specifically about which branches we 
can create to host active development to make our subprojet (a Neutron 
service plugin) work with the last Openstack release and to backport it 
with to earlier releases.


Here are precisely the assumptions that we've made, largely based on the 
fact that the project is tagged 'release-independent' (meaning 
"completely bypass the 6-month cycle and release independently" [1]):
a) that we can make a release targeting Liberty much later than the 
release date of Liberty
b) that we could make releases more frequent than the 6-month cycle ; 
not only bugfix releases but also feature releases
c) that the idea of a release-independent project being backported to 
work with past Openstack releases is acceptable (of course, without 
requiring any change in release-managed projects, something largely 
possible in many cases for projects such as a Neutron service plugin or 
an ML2 driver)


Note that we aren't the only big tent project having this kind of 
expectations (e.g. [3]).


The rest of this email follows from these assumptions.

To do (a) and (c) we need separate branches in which to do active work.
We have understood clearly that given the contract around 'stable/*' 
branches, the branches in which to do this active work cannot be named 
'stable/*'.


Where we are today:
- we do active development, planning a liberty release soon, on our 
'master' branch
- we have a 'backport/kilo' and a 'backport/juno' branches in which we 
plan to make the necessary changes to adapt with Neutron kilo and juno; 
these branches were created by Neutron core devs for us [5], based on 
the common understanding that choosing 'stable/*' branch names for 
branches with active development would be a huge no no


Let me take a few example of the issues we hit...

I apologize in advance for imprecisions that may result from my limited 
experience with the Openstack project at large, and CI subtleties in 
particular.


### Continuous Integration issue

Our master branch is written to work with stable/liberty of other 
projects we depend on (neutron, python-neutronclient, devstack for the 
CI devstack VMs).  The issue we hit, at least this is my understanding, 
is that the CI system (at least the devstack VM parts) has a built-in 
implicit assumption that branch X of project foo is meant to work with 
branch X of project bar, but that this assumption is not true in our case.


The solution we could consider is to tweak CI gate jobs to add jobs that 
force a specific branch to be used for Openstack key project our job 
depend on (e.g. devstack, neutron, in our case), and filter which of 
these jobs would be triggered for each specific branch of our project.


For instance:
- define a gate-install-dsvm-networking-bgpvpn-kilo with branch-override 
stable/kilo  (will result in creating a devstack stable/kilo with 
Neutron stable/kilo inside)
- configure zuul to apply this job *only if* the gerrit change 
triggering the test is for our backport/kilo branch
(do that again for our juno branch, and again to map our master to 
Openstack stable/liberty)


It seems like it would work, although possible too verbose.

With the infra team support we already have something close to this 
configuration in place for our master (two jobs, one to test with 
master, one to force testing against stable/liberty). [4]


### Synchronizing requirements issue

Trying to be good pupils we had activated the check-requirements jobs in 
our zuul config, and the requirements proposal bot as well.
Just like the CI system, these requirements tools have a built-in 
implicit assumption that branch X of project foo is meant to work with 
branch X of project bar, which breaks in our case.


The issues we have are the following:
1- the botis proposing on our 'master' branch, updates to 
requirements.txt to make us in sync with the requirements 'master' 
branch, which is irrelevant since our master in facts targets Liberty  
-- this is easily "solved": we just ignore those proposed changes
2- the bot won't be able to propose anything relevant on our 
backport/kilo and backport/juno branches, since he does not know they 
target stable/kilo and stable/juno  -- we can live with that and update 
requirements ourselves
3- we can't update our requirements.txt on our master branch: we want to 
add requirements conforming with Liberty, but the check-requirements 
jobs thinks this is wrong since it checks our master branch against its 
master branch (that now has mitaka requirements)
4- same as 3 for our backport/kilo and backport/juno branches (the job 
does not know 

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

[Thomas Morin]

Hi Ihar,

Ihar Hrachyshka :

Reviving the thread.
[...] (I appreciate if someone checks me on the following though):


This is an excellent recap.



 I set up a new etherpad to collect feedback from subprojects [2].


I've filled in details for networking-bgpvpn.
Please tell me if you need more information.



Once we collect use cases there and agree on agent API for extensions 
(even if per agent type), we will implement it and define as stable 
API, then pass objects that implement the API into extensions thru 
extension manager. If extensions support multiple agent types, they 
can still distinguish between which API to use based on agent type 
string passed into extension manager.


I really hope we start to collect use cases early so that we have time 
to polish agent API and make it part of l2 extensions earlier in 
Mitaka cycle.


We'll be happy to validate the applicability of this approach as soon as 
something is ready.


Thanks for taking up this work!

-Thomas




Ihar Hrachyshka  wrote:

On 30 Sep 2015, at 12:53, Miguel Angel Ajo  
wrote:




Ihar Hrachyshka wrote:

On 30 Sep 2015, at 12:08, thomas.mo...@orange.com wrote:

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 number (read-only)
- local_vlan_map dict (read-only)
- setup_entry_for_arp_reply method (called to add static ARP 
entries)

Sounds very tightly coupled to OVS agent.
Please bear in mind, the extension interface will be available 
from different agent types
(OVS, SR-IOV, [eventually LB]), so this interface you're 
talking about could also serve as
a translation driver for the agents (where the translation is 
possible), I totally understand
that most extensions are specific agent bound, and we must be 
able to identify

the agent we're serving back exactly.
Yes, I do have this in mind, but what we've identified for now 
seems to be OVS specific.
Indeed it does. Maybe you can try to define the needed pieces in 
high level actions, not internal objects you need to access to. 
Like ‘- connect endpoint X to Y’, ‘determine segmentation id for 
a network’ etc.
I've been thinking about this, but would tend to reach the 
conclusion that the things we need to interact with are pretty 
hard to abstract out into something that would be generic across 
different agents.  Everything we need to do in our case relates to 
how the agents use bridges and represent networks internally: 
linuxbridge has one bridge per Network, while OVS has a limited 
number of bridges playing different roles for all networks with 
internal segmentation.


To look at the two things you  mention:
- "connect endpoint X to Y" : what we need to do is redirect the 
traffic destinated to the gateway of a Neutron network, to the 
thing that will do the MPLS forwarding for the right BGP VPN 
context (called VRF), in our case br-mpls (that could be done with 
an OVS table too) ; that action might be abstracted out to hide 
the details specific to OVS, but I'm not sure on how to  name the 
destination in a way that would be agnostic to these details, and 
this is not really relevant to do until we have a relevant context 
in which the linuxbridge would pass packets to something doing 
MPLS forwarding (OVS is currently the only option we support for 
MPLS forwarding, and it does not really make sense to mix 
linuxbridge for Neutron L2/L3 and OVS for MPLS)
- "determine segmentation id for a network": this is something 
really OVS-agent-specific, the linuxbridge agent uses multiple 
linux bridges, and does not rely on internal segmentation


Completely abstracting out packet forwarding pipelines in OVS and 
linuxbridge agents would possibly allow defining an interface that 
agent extension could use without to know about anything specific 
to OVS or the linuxbridge, but I believe this is a very 
significant taks to tackle.


If you look for a clean way to integrate with reference agents, 
then it’s something that we should try to achieve. I agree it’s not 
an easy thing.


Just an idea: can we have a resource for traffic forwarding, 
similar to security groups? I know folks are not ok with extending 
security groups API due to compatibility reasons, so maybe fwaas is 
the place to experiment with it.


Hopefully it will be acceptable to create an interface, even it 
exposes a set of methods specific to the linuxbridge agent and a 
set of methods specific to the OVS agent.  That would mean that 
the agent extension that can work in both contexts (not our case 
yet) would check the agent type before using the first set or the 
second set.


The assumption of the whole idea of l2 agent extensions is that 
they are agent agnostic. In case of QoS, we implemented a common 
QoS extension that 

Re: [openstack-dev] [Neutron] Gerrit permissions and Merge rights

[Thomas Morin]

Doug Wiegley :
As an alternative, to be considered to cleaned up, note that octavia, 
also a neutron stadium project, puts its specs in its own repo, runs 
its own doc jobs, etc. Pros and cons, but just pointing out that its 
out there.


Same for networking-bgpvpn: while the base discussion on the API 
introduced by this project initially happened in neutron-specs [1], we 
now host it in our repo [2] (doc dir, doc  jobs and new specs to be 
reviewed will be in this repo as well).


This is works for us today.

-Thomas

[1] https://review.openstack.org/#/c/177740/
[2] http://docs.openstack.org/developer/networking-bgpvpn/




On Oct 22, 2015, at 2:47 AM, Kyle Mestery > wrote:


On Wed, Oct 21, 2015 at 12:34 PM, Armando M.>wrote:




On 21 October 2015 at 10:29, Kyle Mestery>wrote:

On Wed, Oct 21, 2015 at 12:08 PM, Armando
M.>wrote:



On 21 October 2015 at 09:53, Kyle
Mestery>wrote:

On Wed, Oct 21, 2015 at 11:37 AM, Armando
M.>wrote:



On 21 October 2015 at 04:12, Gal
Sagie>wrote:

Do we also want to consider Project Kuryr
part of this?


No, why would we?

The reason to consider it is because Kuryr is a
sub-project of Neutron, and they are doing their spec
submissions following the Neutron guidelines. Adding
the kuryr-core gerrit group to be on part with the
*aas repos makes sense here. If other sub-projects
(like L2FW, SFC, etc.) start doing spec reviews in
the neutron-specs repository, then adding them makes
sense too.


I don't believe this is the road we set ourselves on when
we started the decomp/stadium. We wanted a clear
separation of concerns and I don't see how going down
this path is going to help us achieve that.

I don't see the grounds to have such an abrupt change in
direction right now, especially for the level of work
that that would imply and the pressure that would put on
the drivers team. Anyone is free to review and contribute
where it matters for them, and location should not
prevent them from doing so.

I was merely implying that since these projects are part of
neutron, and they have specs, keeping them in one place makes
sense. And by doing that, we'd need to give them +2 powers
for their core reviewers. But, I'm fine with leaving things
the way they are and having them put their specs in their
devref. But we should update the devref in Neutron to reflect
this, e.g. that we don't expect specs in neutron-specs for
things outside [neutron, neutron-fwaas, neutron-lbaas,
neutron-vpnaas].


IMO, it's pretty clear from here [1], which I revised in the
context of [2]. Not sure if there's anything else that's left to
misunderstanding.


I think this [1] helps to make it 100% clearer, at least to me.

[1]https://review.openstack.org/238190


[1]http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#neutron-specs-core-reviewer-team
[2] https://review.openstack.org/#/c/237180/

We already started sending Kuryr spec to the
Neutron repository and I think it would make
sense to manage it
as part of Neutron spec process.


No, unless what you are asking are changes to the
core. Do you have a reference for me to look at?

See above, perhaps I answered this for you.



Any opinions on that?

Gal.

On Tue, Oct 20, 2015 at 11:10 PM, Armando
M.>wrote:

Hi folks,

During revision of the Neutron teams [1],
we made clear that the neutron-specs repo
is to be targeted by specs for all the
Neutron projects (core + *-aas).

For this reason I made sure that the
neutron-specs-core team +2 right was
extended to all the core teams.

Be mindful, use your +2 

Re: [openstack-dev] [Neutron] [RFC] Floating IP idea solicitation and collaboration

[Thomas Morin]

Hi Keshava,

2014-12-15 11:52, A, Keshava :

I have been thinking of Starting MPLS right from CN for L2VPN/EVPN 
scenario also.

Below are my queries w.r.t supporting MPLS from OVS :
1. MPLS will be used even for VM-VM traffic across CNs 
generated by OVS  ?


If E-VPN is used only to interconnect outside of a Neutron domain, then 
MPLS does not have to be used for traffic between VMs.


If E-VPN is used inside one DC for VM-VM traffic, then MPLS is *one* of 
the possible encapsulation only: E-VPN specs have been defined to use 
VXLAN (handy because there is native kernel support), MPLS/GRE or 
MPLS/UDP are other possibilities.



2. MPLS will be originated right from OVS and will be mapped at 
Gateway (it may be NN/Hardware router ) to SP network ?
So MPLS will carry 2 Labels ? (one for hop-by-hop, and 
other one for end to identify network ?)


On will carry 2 Labels ? : this would be one possibility, but not the 
one we target.
We would actually favor MPLS/GRE (GRE used instead of what you call the 
MPLS hop-by-hop label) inside the DC -- this requires only one label.
At the DC edge gateway, depending on the interconnection techniques to 
connect the WAN, different options can be used (RFC4364 section 10): 
Option A with back-to-back VRFs (no MPLS label, but typically VLANs), or 
option B (with one MPLS label), a mix of A/B is also possible and 
sometimes called option D (one label) ;  option C also exists, but is 
not a good fit here.


Inside one DC, if vswitches see each other across an Ethernet segment, 
we can also use MPLS with just one label (the VPN label) without a GRE 
encap.


In a way, you can say that in Option B, the label are mapped at the 
DC/WAN gateway(s), but this is really just MPLS label swaping, not to be 
misunderstood as mapping a DC label space to a WAN label space (see 
below, the label space is local to each device).




3. MPLS will go over even the network physical infrastructure 
 also ?


The use of MPLS/GRE means we are doing an overlay, just like your 
typical VXLAN-based solution, and the network physical infrastructure 
does not need to be MPLS-aware (it just needs to be able to carry IP 
traffic)



4. How the Labels will be mapped a/c virtual and physical world 
?


(I don't get the question, I'm not sure what you mean by mapping labels)


5. Who manages the label space  ? Virtual world or physical 
world or both ? (OpenStack +  ODL ?)


In MPLS*, the label space is local to each device : a label is 
downstream-assigned, i.e. allocated by the receiving device for a 
specific purpose (e.g. forwarding in a VRF). It is then (typically) 
avertized in a routing protocol; the sender device will use this label 
to send traffic to the receiving device for this specific purpose.  As a 
result a sender device may then use label 42 to forward traffic in the 
context of VPN X to a receiving device A, and the same label 42 to 
forward traffic in the context of another VPN Y to another receiving 
device B, and locally use label 42 to receive traffic for VPN Z.  There 
is no global label space to manage.


So, while you can design a solution where the label space is managed in 
a centralized fashion, this is not required.


You could design an SDN controller solution where the controller would 
manage one label space common to all nodes, or all the label spaces of 
all forwarding devices, but I think its hard to derive any interesting 
property from such a design choice.


In our BaGPipe distributed design (and this is also true in OpenContrail 
for instance) the label space is managed locally on each compute node 
(or network node if the BGP speaker is on a network node). More 
precisely in VPN implementation.


If you take a step back, the only naming space that has to be managed 
in BGP VPNs is the Route Target space. This is only in the control 
plane. It is a very large space (48 bits), and it is structured (each AS 
has its own 32 bit space, and there are private AS numbers). The mapping 
to the dataplane to MPLS labels is per-device and purely local.


(*: MPLS also allows upstream-assigned labels, it is more recent and 
only used in specific cases where downstream assigned does not work well)



6. The labels are nested (i.e. Like L3 VPN end to end MPLS 
connectivity ) will be established ?


In solutions where MPLS/GRE is used the label stack typically has only 
one label (the VPN label).




7. Or it will be label stitching between Virtual-Physical 
network ?
How the end-to-end path will be setup ?

Let me know your opinion for the same.



How the end-to-end path is setup may depend on interconnection choice.
With an inter-AS option B or A+B, you would have the following:
- ingress DC overlay: one MPLS-over-GRE hop from vswitch to DC edge
- ingress DC edge to WAN: one MPLS label (VPN label 

Re: [openstack-dev] [Neutron] [RFC] Floating IP idea solicitation and collaboration

[Thomas Morin]

Hi Ryan,

Mathieu Rohon :

We have been working on similar Use cases to announce /32 with the
Bagpipe BGPSpeaker that supports EVPN.


Btw, the code for the BGP E-VPN implementation is at 
https://github.com/Orange-OpenSource/bagpipe-bgp
It reuses parts of ExaBGP (to which we contributed encodings for E-VPN 
and IP VPNs) and relies on the VXLAN native Linux kernel implementation 
for the E-VPN dataplane.


-Thomas


Please have a look at use case B in [1][2].
Note also that the L2population Mechanism driver for ML2, that is
compatible with OVS, Linuxbridge and ryu ofagent, is inspired by EVPN,
and I'm sure it could help in your use case

[1]http://fr.slideshare.net/ThomasMorin1/neutron-and-bgp-vpns-with-bagpipe
[2]https://www.youtube.com/watch?v=q5z0aPrUZYcsns
[3]https://blueprints.launchpad.net/neutron/+spec/l2-population

Mathieu

On Thu, Dec 4, 2014 at 12:02 AM, Ryan Clevenger
ryan.cleven...@rackspace.com wrote:

Hi,

At Rackspace, we have a need to create a higher level networking service
primarily for the purpose of creating a Floating IP solution in our
environment. The current solutions for Floating IPs, being tied to plugin
implementations, does not meet our needs at scale for the following reasons:

1. Limited endpoint H/A mainly targeting failover only and not multi-active
endpoints,
2. Lack of noisy neighbor and DDOS mitigation,
3. IP fragmentation (with cells, public connectivity is terminated inside
each cell leading to fragmentation and IP stranding when cell CPU/Memory use
doesn't line up with allocated IP blocks. Abstracting public connectivity
away from nova installations allows for much more efficient use of those
precious IPv4 blocks).
4. Diversity in transit (multiple encapsulation and transit types on a per
floating ip basis).

We realize that network infrastructures are often unique and such a solution
would likely diverge from provider to provider. However, we would love to
collaborate with the community to see if such a project could be built that
would meet the needs of providers at scale. We believe that, at its core,
this solution would boil down to terminating north-south traffic
temporarily at a massively horizontally scalable centralized core and then
encapsulating traffic east-west to a specific host based on the
association setup via the current L3 router's extension's 'floatingips'
resource.

Our current idea, involves using Open vSwitch for header rewriting and
tunnel encapsulation combined with a set of Ryu applications for management:

https://i.imgur.com/bivSdcC.png

The Ryu application uses Ryu's BGP support to announce up to the Public
Routing layer individual floating ips (/32's or /128's) which are then
summarized and announced to the rest of the datacenter. If a particular
floating ip is experiencing unusually large traffic (DDOS, slashdot effect,
etc.), the Ryu application could change the announcements up to the Public
layer to shift that traffic to dedicated hosts setup for that purpose. It
also announces a single /32 Tunnel Endpoint ip downstream to the TunnelNet
Routing system which provides transit to and from the cells and their
hypervisors. Since traffic from either direction can then end up on any of
the FLIP hosts, a simple flow table to modify the MAC and IP in either the
SRC or DST fields (depending on traffic direction) allows the system to be
completely stateless. We have proven this out (with static routing and
flows) to work reliably in a small lab setup.

On the hypervisor side, we currently plumb networks into separate OVS
bridges. Another Ryu application would control the bridge that handles
overlay networking to selectively divert traffic destined for the default
gateway up to the FLIP NAT systems, taking into account any configured
logical routing and local L2 traffic to pass out into the existing overlay
fabric undisturbed.

Adding in support for L2VPN EVPN
(https://tools.ietf.org/html/draft-ietf-l2vpn-evpn-11) and L2VPN EVPN
Overlay (https://tools.ietf.org/html/draft-sd-l2vpn-evpn-overlay-03) to the
Ryu BGP speaker will allow the hypervisor side Ryu application to advertise
up to the FLIP system reachability information to take into account VM
failover, live-migrate, and supported encapsulation types. We believe that
decoupling the tunnel endpoint discovery from the control plane
(Nova/Neutron) will provide for a more robust solution as well as allow for
use outside of openstack if desired.




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Thomas Morin]

Hi,

2014-06-22, A, Keshava:


I have some of the basic question about deployment model of using this BaGPipe 
BGP in virtual cloud network.

1. We want MPLS to start right from compute node as part Tennant traffic ?


BaGPipe BGP component is indeed adapted to be run on compute nodes to 
encapsulate tenant traffic as MPLS traffic toward BGP IP VPNs external 
to the datacenter. In this case you are interconnecting each VM at once 
with a /32 VPNv4 route.  [A]


But you could use it as well on a network node to interconnect a whole 
virtual network with one BGP route. However doing so does not simplify 
deployments and requires additional care to handle redundancy.


And to implement virtual networks with BaGPipe, the proposed target 
would be to use it on compute nodes; but in that case MPLS is not the 
only option, and what we currently support is VXLAN (E-VPN with a VXLAN 
encapsulation).




2. We want L3 VRF separation right on Compute nodes (or NN Node) ?
Tenant = VRF ?
Tenant span can be across multiple CN nodes,  then have BGP to Full 
mesh with in CN ?


As said in another comment, a tenant (or project depending on the 
terminology) is not a network construct; tenants just own networks.


In [A] above, for a virtual network interconnected with a VPN, there 
would be one VRF on each compute node with a VM connected to this 
virtual network.


(I'm not getting your question on having BGP as a full mesh in compute 
nodes)



3. How to have  E-VPN connectivity mapping at NN/CN nodes ?
 Is there an L2 VPN psuedowire thinking from CN nodes itself ?


I'm not sure I get your question.
When BaGPipe BGP is used on compute nodes to build a virtual network, NN 
don't need to be involved.  They only will be involved once a router 
port (on a NN) is connected to a virtual network.


Note also that in E-VPN there is no notion of pseudowire; E-VPN does not 
involve learning on incoming (MPLS- or VXLAN-) encapsulated traffic, and 
forwarding tables involve dynamically adding an encap header based on a 
static forwarding table (rather than tunnels or pseudowires).




4. Tennant traffic is L2 or L3 or MPLS ? Where will be L2 terminated ?



When E-VPN is used, network traffic inside a virtual network is carried 
as Ethernet in VXLAN, MPLS or MPLS-over-GRE (note that today BaGPipe 
does not support any MPLS dataplane driver for E-VPN).  When IP VPN is 
used (eg. between virtual networks, or to/from an external IP VPN), 
traffic is carried as IP traffic in MPLS or MPLS-GRE.



Help me understand the deployment model for this .



Hope that helps,

-Thomas



-Original Message-
From: Thomas Morin [mailto:thomas.mo...@orange.com]
Sent: Thursday, June 19, 2014 9:32 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal

Hi everyone,

Sorry, I couldn't make it in time for the IRC meeting.

Just saw in the logs:
15:19:12 yamamoto are orange folks here?  they might want to
  introduce their bgp speaker.

The best intro to BaGPipe BGP is the README on github:
https://github.com/Orange-OpenSource/bagpipe-bgp/blob/master/README.md

Beyond just speaking the BGP protocol on the wire, BaGPipe is a an 
implementation of BGP VPNs (IP VPNs and E-VPNs) including the forwarding part. 
It can be run as a service exposing a REST API, or a library inside an agent; 
it handles the lifecylcle of VRFs and port attached/detached from them and 
appropriately circulates event to/from BGP peers based on VRF import/export 
rules and RTC publish/subscribe semantics.  It's complete enough to let us 
build neutron virtual networks with IP VPNs, and interconnect them with 
external VPNs; the parts for Opentsack integration are not on this github, I'm 
just mentioning this for the sake of illustrating the relative maturity.

Although it does not address plain IP, this would I believe by a really easy 
addition to make.

I'll do my best to attend next week IRC meeting, but until this, feel free to ask.  
We can also do a QA session on IRC if that sounds convenient.

Best,

-Thomas



2014-06-13, YAMAMOTO Takashi:

an update after today's l3 meeting:
here's a new version of ryu bgp api patch.
http://sourceforge.net/p/ryu/mailman/message/32453021/


it has been merged to the ryu master.
  https://github.com/osrg/ryu.git

here's formatted documentation:
  http://ryu.readthedocs.org/en/latest/library_bgp_speaker.html
  http://ryu.readthedocs.org/en/latest/library_bgp_speaker_ref.html

YAMAMOTO Takashi



YAMAMOTO Takashi


I have seen the Ryu team is involved and responsive to the community.
That goes a long way to support it as the reference implementation
for BPG speaking in Neutron.  Thank you for your support.  I'll look
forward to the API and documentation refinement

Let's be sure to document any work that needs to be done so that it
will support the features we need.  We can use the comparison page

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

[Thomas Morin]

Hi,

2014-06-22, A, Keshava:


I have some of the basic question about deployment model of using this BaGPipe 
BGP in virtual cloud network.

1. We want MPLS to start right from compute node as part Tennant traffic ?


BaGPipe BGP component is indeed adapted to be run on compute nodes to 
encapsulate tenant traffic as MPLS traffic toward BGP IP VPNs external 
to the datacenter. In this case you are interconnecting each VM at once 
with a /32 VPNv4 route.  [A]


But you could use it as well on a network node to interconnect a whole 
virtual network with one BGP route. However doing so does not simplify 
deployments and requires additional care to handle redundancy.


And to implement virtual networks with BaGPipe, the proposed target 
would be to use it on compute nodes; but in that case MPLS is not the 
only option, and what we currently support is VXLAN (E-VPN with a VXLAN 
encapsulation).




2. We want L3 VRF separation right on Compute nodes (or NN Node) ?
Tenant = VRF ?
Tenant span can be across multiple CN nodes,  then have BGP to Full 
mesh with in CN ?


As said in another comment, a tenant (or project depending on the 
terminology) is not a network construct; tenants just own networks.


In [A] above, for a virtual network interconnected with a VPN, there 
would be one VRF on each compute node with a VM connected to this 
virtual network.


(I'm not getting your question on having BGP as a full mesh in compute 
nodes)



3. How to have  E-VPN connectivity mapping at NN/CN nodes ?
 Is there an L2 VPN psuedowire thinking from CN nodes itself ?


I'm not sure I get your question.
When BaGPipe BGP is used on compute nodes to build a virtual network, NN 
don't need to be involved.  They only will be involved once a router 
port (on a NN) is connected to a virtual network.


Note also that in E-VPN there is no notion of pseudowire; E-VPN does not 
involve learning on incoming (MPLS- or VXLAN-) encapsulated traffic, and 
forwarding tables involve dynamically adding an encap header based on a 
static forwarding table (rather than tunnels or pseudowires).




4. Tennant traffic is L2 or L3 or MPLS ? Where will be L2 terminated ?



When E-VPN is used, network traffic inside a virtual network is carried 
as Ethernet in VXLAN, MPLS or MPLS-over-GRE (note that today BaGPipe 
does not support any MPLS dataplane driver for E-VPN).  When IP VPN is 
used (eg. between virtual networks, or to/from an external IP VPN), 
traffic is carried as IP traffic in MPLS or MPLS-GRE.



Help me understand the deployment model for this .



Hope that helps,

-Thomas



-Original Message-
From: Thomas Morin [mailto:thomas.mo...@orange.com]
Sent: Thursday, June 19, 2014 9:32 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal

Hi everyone,

Sorry, I couldn't make it in time for the IRC meeting.

Just saw in the logs:
15:19:12 yamamoto are orange folks here?  they might want to
  introduce their bgp speaker.

The best intro to BaGPipe BGP is the README on github:
https://github.com/Orange-OpenSource/bagpipe-bgp/blob/master/README.md

Beyond just speaking the BGP protocol on the wire, BaGPipe is a an 
implementation of BGP VPNs (IP VPNs and E-VPNs) including the forwarding part. 
It can be run as a service exposing a REST API, or a library inside an agent; 
it handles the lifecylcle of VRFs and port attached/detached from them and 
appropriately circulates event to/from BGP peers based on VRF import/export 
rules and RTC publish/subscribe semantics.  It's complete enough to let us 
build neutron virtual networks with IP VPNs, and interconnect them with 
external VPNs; the parts for Opentsack integration are not on this github, I'm 
just mentioning this for the sake of illustrating the relative maturity.

Although it does not address plain IP, this would I believe by a really easy 
addition to make.

I'll do my best to attend next week IRC meeting, but until this, feel free to ask.  
We can also do a QA session on IRC if that sounds convenient.

Best,

-Thomas



2014-06-13, YAMAMOTO Takashi:

an update after today's l3 meeting:
here's a new version of ryu bgp api patch.
http://sourceforge.net/p/ryu/mailman/message/32453021/


it has been merged to the ryu master.
  https://github.com/osrg/ryu.git

here's formatted documentation:
  http://ryu.readthedocs.org/en/latest/library_bgp_speaker.html
  http://ryu.readthedocs.org/en/latest/library_bgp_speaker_ref.html

YAMAMOTO Takashi



YAMAMOTO Takashi


I have seen the Ryu team is involved and responsive to the community.
That goes a long way to support it as the reference implementation
for BPG speaking in Neutron.  Thank you for your support.  I'll look
forward to the API and documentation refinement

Let's be sure to document any work that needs to be done so that it
will support the features we need.  We can use the comparison page

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

[Thomas Morin]

Hi Ian,

Ian Wells :


When you say things like 'tenant = VRF' (and, in fact, I presume you 
mean 'network = VRF', since networks and tenants are two different 
things) then that's actually more to do with how you implement the 
networking overlay layer in Neutron.  While interesting, and while it 
could potentially use a BGP speaker and VRFs to do it, it's not the 
same use case as advertising routes externally, or terminating an 
external MPLS VPN in Openstack.  I could do either of those things 
independently of the other. Terminating VPNs requires an extension API 
and could potentially glue on to a current plugin (much like VPNaaS). 
Writing overlays is a new plugin entirely.


Indeed.



There's a use for BGP speakers in both arenas (and additionally within 
the distributed virtual router, which is a third case) so perhaps we 
could address who's using which speaker for precisely what?


We plan to propose an implementation of the BGP VPN interconnection API 
( https://review.openstack.org/#/c/93329/1 ) that will use BaGPipe BGP 
for IP VPN VRF.
And we are also working on a mechanism driver that will use BaGPipe BGP 
and E-VPN/VXLAN.


Best,

-Thomas
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Thomas Morin]

Hi everyone,

Sorry, I couldn't make it in time for the IRC meeting.

Just saw in the logs:
15:19:12 yamamoto are orange folks here?  they might want to
introduce their bgp speaker.

The best intro to BaGPipe BGP is the README on github:
https://github.com/Orange-OpenSource/bagpipe-bgp/blob/master/README.md

Beyond just speaking the BGP protocol on the wire, BaGPipe is a an 
implementation of BGP VPNs (IP VPNs and E-VPNs) including the forwarding 
part. It can be run as a service exposing a REST API, or a library 
inside an agent; it handles the lifecylcle of VRFs and port 
attached/detached from them and appropriately circulates event to/from 
BGP peers based on VRF import/export rules and RTC publish/subscribe 
semantics.  It's complete enough to let us build neutron virtual 
networks with IP VPNs, and interconnect them with external VPNs; the 
parts for Opentsack integration are not on this github, I'm just 
mentioning this for the sake of illustrating the relative maturity.


Although it does not address plain IP, this would I believe by a really 
easy addition to make.


I'll do my best to attend next week IRC meeting, but until this, feel 
free to ask.  We can also do a QA session on IRC if that sounds convenient.


Best,

-Thomas



2014-06-13, YAMAMOTO Takashi:

an update after today's l3 meeting:
here's a new version of ryu bgp api patch.
http://sourceforge.net/p/ryu/mailman/message/32453021/


it has been merged to the ryu master.
 https://github.com/osrg/ryu.git

here's formatted documentation:
 http://ryu.readthedocs.org/en/latest/library_bgp_speaker.html
 http://ryu.readthedocs.org/en/latest/library_bgp_speaker_ref.html

YAMAMOTO Takashi



YAMAMOTO Takashi


I have seen the Ryu team is involved and responsive to the community.
That goes a long way to support it as the reference implementation for
BPG speaking in Neutron.  Thank you for your support.  I'll look
forward to the API and documentation refinement

Let's be sure to document any work that needs to be done so that it
will support the features we need.  We can use the comparison page for
now [1] to gather that information (or links).  If Ryu is lacking in
any area, it will be good to understand the timeline on which the
features can be delivered and stable before we make a formal decision
on the reference implementation.

Carl

[1] https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison

On Thu, Jun 5, 2014 at 10:36 AM, Jaume Devesa devv...@gmail.com wrote:

After watch the documentation and the code of exabgp and Ryu, I find the Ryu
speaker much more easy to integrate and pythonic than exabgp. I will use it
as well as reference implementation in the Dynamic Routing bp.

Regards,


On 5 June 2014 18:23, Nachi Ueno na...@ntti3.com wrote:



Yamamoto

Cool! OK, I'll make ryu based bgpspeaker as ref impl for my bp.


Yong

Ya, we have already decided to have the driver architecture.
IMO, this discussion is for reference impl.

2014-06-05 0:24 GMT-07:00 Yongsheng Gong gong...@unitedstack.com:

I think maybe we can device a kind of framework so that we can plugin
different BGP speakers.


On Thu, Jun 5, 2014 at 2:59 PM, YAMAMOTO Takashi
yamam...@valinux.co.jp
wrote:


hi,


ExaBgp was our first choice because we thought that run something in
library mode would be much more easy to deal with (especially the
exceptions and corner cases) and the code would be much cleaner. But
seems
that Ryu BGP also can fit in this requirement. And having the help
from
a
Ryu developer like you turns it into a promising candidate!

I'll start working now in a proof of concept to run the agent with
these
implementations and see if we need more requirements to compare
between
the
speakers.


we (ryu team) love to hear any suggestions and/or requests.
we are currently working on our bgp api refinement and documentation.
hopefully they will be available early next week.

for both of bgp blueprints, it would be possible, and might be
desirable,
to create reference implementations in python using ryu or exabgp.
(i prefer ryu. :-)

YAMAMOTO Takashi

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





--
Jaume Devesa
Software Engineer at Midokura

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org