from:"thomas.morin"

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

2018-10-02 Thread thomas.morin


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 (networking-bgpvpn) and given that 
networking-bagpipe is used as reference driver, it exercises a large 
portion of networking-bagpipe as well).


Having this one will help a lot.

Thanks,

-Thomas


On 9/30/18 2:42 AM, Miguel Lavalle wrote:

Dear networking Stackers,

During the recent PTG in Denver, we discussed measures to prevent 
patches merged in the Neutron repo breaking Stadium and related 
networking projects in general. We decided to implement the following:


1) For Stadium projects, we want to add non-voting jobs to the Neutron 
check queue

2) For non stadium projects, we are inviting them to add 3rd party CI jobs

The next step is for each project to propose the jobs that they want 
to run against Neutron patches.


Best regards

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


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


__
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

2018-09-05 Thread thomas.morin

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 Thode wrote:

On 18-08-31 19:52:09, Matthew Thode wrote:

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.

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).
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).

The requirements team has gone ahead and made a aweful hack to get gate
unwedged. The commit message is a very good summary of our reasoning
why it has to be this way for now. My comment explains our plan going
forward (there will be a revert prepared as soon as this merges for
instance).

step 1. merge this
step 2. look into and possibly fix our tooling (why was the gitref addition not
rejected by gate)
step 3. fix networking-odl (release ceilometer)
step 4. unmerge this

__
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

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.

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

2018-06-07 Thread thomas.morin


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 , the tox-siblings magic would prevent us from pinning 
our networking-odl dep to a pypi release)
- the side effect, as you identified, is that this breaks stable/* 
branches of networking-bgpvpn, which still use toos/tox_install.sh (and 
can't stop doing so because in stable branches, the requirement checking 
job still prevents the addition of networking-odl in requirements.txt)


I think that, if doable, it would be nice to avoid complexifying the 
zuul job configuration to keep networking-odl.
If it can't be avoided then something like your change  [3] would be the 
way, I guess.


Andreas, Monty, any guidance ?

-Thomas

[3] https://review.openstack.org/#/c/572495/



On 06/06/2018 13:28, Elõd Illés wrote:

Hi,

I'm trying to create a fix for the failing networking-bgpvpn stable 
periodic sphinx-docs job [1], but meanwhile it turned out that other 
"check" (and possibly "gate") jobs are failing on stable, too, on 
networking-bgpvpn, because of missing dependency: networking-odl 
repository (for pep8, py27, py35, cover and even sphinx, too). I 
submitted a patch a couple of days ago for the stable periodic py27 
job [2] and it solved the issue there. But now it seems that every 
other networking-bgpvpn job needs this fix if it is run against stable 
branches (something like in this patch [3]).


Question: Is there a better way to fix these issues?


The common error message of the failing jobs:
**
ERROR! /home/zuul/src/git.openstack.org/openstack/networking-odl not 
found

In Zuul v3 all repositories used need to be declared
in the 'required-projects' parameter on the job.
To fix this issue, add:

  openstack/networking-odl

to 'required-projects'.

While you're at it, it's worth noting that zuul-cloner itself
is deprecated and this shim is only present for transition
purposes. Start thinking about how to rework job content to
just use the git repos that zuul will place into
/home/zuul/src/git.openstack.org directly.
**


[1] https://review.openstack.org/#/c/572368/
[2] https://review.openstack.org/#/c/569111/
[3] https://review.openstack.org/#/c/572495/


Thanks,

Előd


__ 


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


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


__
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][horizon][neutron] plugins depending on services

2018-04-27 Thread thomas.morin


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 should do though.


A few comments... (below)


On 25/04/2018 16:40, Monty Taylor wrote:


projects with test requirements on git repo urls of other projects
--

There are a bunch of projects that need, for testing purposes, to 
depend on other projects. The majority are either neutron or horizon 
plugins, but conceptually there is nothing neutron or horizon specific 
about the issue. The problem they're trying to deal with is that they 
are a plugin to a service and they need to be able to import code from 
the service they are a plugin to in their unit tests.


(using neutron to avoid being too abstract, but this generalizes to 
other components with plugins)


True, but sometimes a change to a neutron plugin may (with or without a 
need to actually import neutron), need to run against a neutron version 
from git (because the change has a Depends-On a Neutron change, or 
because the change depends on something that is in neutron master but 
not in a release).  We have this when the plugin depends on a new or 
fixed behavior.


While this case can in theory be fixed by moving the code introducing 
the fixed or new behavior into neutron-lib,  it doesn't mean that this 
is always feasible (because the work required to move this part of the 
code to neutron-lib hasn't happened).







unwinding things


There are a few different options, but it's important to keep in mind 
that we ultimately want all of the following:


* The code works
* Tests can run properly in CI
* "Depends-On" works in CI so that you can test changes cross-repo


Note that this was true with tools/tox_install.sh, but broke when it was 
removed for a job such as legacy-networking-bgpvpn-dsvm-functional (see 
[1]) which does not inherit from zuul tox jobs, but still relies 
ultimately on zuul to run the test.


[1] 
http://logs.openstack.org/41/558741/11/check/legacy-networking-bgpvpn-dsvm-functional/86a743c/



* Tests can run properly locally for developers


(Broke when tools/tox_install.sh was abandoned, currently causing minor 
pain to lots of people working on neutron-plugins unless py27-dev hacks 
are in place in their project)




* Deployment requirements are accurately communicated to deployers


Was definitely improved by removing tools/tox_install.sh!




Specific Suggestions


As there are a few different scenarios, I want to suggest we do a few 
different things.


* Prefer interface libraries on PyPI that projects depend on

Like python-openstackclient and osc-lib, this is the *best* approach
for projects with plugins. Such interface libraries need to be able to 
do intermediate releases - and those intermediate releases need to not 
break the released version of the projects. This is the hardest and 
longest thing to do as well, so it's most likely to be a multi-cycle 
effort.


I would object to "best", for the following reasons:
- because this is not the starting point, the effort to librarize code 
is significant, and it's seems a fact that people don't rush to do it
- there is a practical drawback of doing that: even for project that 
have compatible release cycle, we have overhead of having to release 
e.g. neutron-lib with the change before we can consume it in neutron or 
a neutron plugin (and we have overhead to test the changes as well, with 
extra jobs to test against master or local .zuul.yaml hacks to force 
Depends-On to test what we want e.g. [x] ) ; a situation that would 
avoid this overhead would I think be superior


[x] https://review.openstack.org/#/c/557660/



* Treat inter-plugin depends as normal library depends

If networking-bgpvpn depends on networking-bagpipe and networking-odl, 
then networking-bagpipe and networking-odl need to be released to PyPI 
just like any other library in OpenStack. These are real runtime 
dependencies.


Juste a side note here: networking-bagpipe and networking-odl provide 
components drivers for their corresponding drivers in networking-bgpvpn, 
they aren't strict runtime dependencies, but only dependencies for a 
scenario where their driver is used. Given that, they were moved as 
test-requirements dependencies recently (only required to run unit tests).


The situation for these drivers is a bit in flux though:
- ODL: the bgpvpn driver for ODL is a v1 driver that became obsolete, 
there is a v2 driver sitting entirely in networking-odl
- bagpipe: the bgpvpn driver for bagpipe could be moved to 
networking-bagpipe entirely  -- the one reason why it hasn't happened 
(apart from inertia) is that is it the reference driver for the 
networking-bgpvpn project, and removing it from

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

2018-04-27 Thread thomas.morin


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 developing their
releases in parallel with the services. Not merging an entire
development cycle's worth of work until release day (whether that's
by way of a feature branch or by just continually rebasing and
stacking in Gerrit) would be a very painful workflow for them, and
having to wait a full release cycle before they could start
integrating support for new features in the service would be equally
unfortunate.


+1



As for merging the plugin and service repositories, they tend to be
developed by completely disparate teams so that could require a fair
amount of political work to solve. Extracting the plugin interface
into a separate library which releases more frequently than the
service does indeed sound like the sanest option, but will also
probably take quite a while for some teams to achieve (I gather
neutron-lib is getting there, but I haven't heard about any work
toward that end in Horizon yet).


+1

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


__
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] [kolla][neutron][requirements][pbr]Use git+https line in requirements.txt break the pip install

2018-04-18 Thread thomas.morin

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 record, a distinct side effect of the same incomplete transition 
is also tracked in [1] : having networking-bgpvpn depend on 
networking-odl from git (relying on black-magic by the tox-siblings 
ansible role and 'required-project' job configuration) would not work 
anymore after the change in networking-odl to depend on ceilometer with 
'-e git+...'.


-Thomas

[1] https://bugs.launchpad.net/networking-odl/+bug/1764371


On 18/04/2018 04:48, Jeffrey Zhang wrote:


Recently, one of networking-odl package breaks kolla's gate[0]. The 
direct issue is ceilometer is added in networking-odl's 
requirements.txt file[1]


Then when install network-odl with upper-contraints.txt file, it will 
raise error like


$ pip install -c 
https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt 
./networking-odl

...
collecting networking-bgpvpn>=8.0.0 (from networking-odl==12.0.1.dev54)
Downloading 
http://pypi.doubanio.com/packages/5a/e5/995be0d53d472f739a7a0bb6c9d9fecbc4936148651aaf56d39f3b65b1f1/networking_bgpvpn-8.0.0-py2-none-any.whl 
(172kB)

  100% || 174kB 12.0MB/s
Collecting ceilometer (from networking-odl==12.0.1.dev54)
Could not find a version that satisfies the requirement ceilometer 
(from networking-odl==12.0.1.dev54) (from versions: )
No matching distribution found for ceilometer (from 
networking-odl==12.0.1.dev54)



But if you just install the networking-odl's requirements.txt file, it 
works



$ pip install -c 
https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt 
-r ./networking-odl/requirements.txt

...
Obtaining ceilometer from 
git+https://git.openstack.org/openstack/ceilometer@master#egg=ceilometer 
(from -r networking-odl/requirements.txt (line 21))
  Cloning https://git.openstack.org/openstack/ceilometer (to revision 
master) to /home/jeffrey/.dotfiles/virtualenvs/test/src/ceilometer

...


Is this expected? and how could we fix this?


[0] https://bugs.launchpad.net/kolla/+bug/1764621
[1] 
https://github.com/openstack/networking-odl/blob/master/requirements.txt#L21


-

-
Regards,
Jeffrey Zhang
Blog: http://xcodest.me 

__
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


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


__
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] Propose Slawek Kaplonski for Neutron core

2017-11-30 Thread thomas.morin

+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 Neutron, becoming the lead of the sub-team focused on
> that set of features. More recently, he has collaborated in the
> implementation of OVO and is an active participant in the CI sub-
> team. His number of code reviews during the Queens cycle is on par
> with the leading core members of the team: http://stackalytics.com/?m
> odule=neutron
> 
> In my opinion, his efforts are highly valuable to the team and we
> will be very lucky to have him as a fully voting core.
> 
> I will keep this nomination open for a week as customary,
> 
> Thank you,
> 
> Miguel
> _
> _
> 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

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


__
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] [kolla] [neutron] PTG cross-platform meetup possibility

2017-09-07 Thread thomas.morin

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
> chaining (SFC), etc?
>  
> If yes, would Tuesday 2 pm work?  I’m thinking about an hour or two
> for the session.

If this happens I'm interested to follow.

-Thomas


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


__
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] - FFE for networking-bagpipe, support for MPLS-over-GRE

2017-08-08 Thread thomas.morin

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
fullstack functional test is not fully ready yet (but should be soon).

The change: https://review.openstack.org/#/c/482571
The RFE: https://bugs.launchpad.net/networking-bagpipe/+bug/1709338

Thanks,

-Thomas


(not waiting for a confirmation that the process applies to stadium
projects, because I'm already late to fill this in, being just back
from PTO)






























































































_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


__
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] - FFE requests for Pike

2017-08-08 Thread thomas.morin

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 the tag and FFE in the
> subject like in [1]. We will discuss them in the drivers meetings.
> 
> 
> 1. http://lists.openstack.org/pipermail/openstack-dev/2017-July/12031
> 0.html
> 
> Thanks,
> Kevin Benton
> _
> _
> 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

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


__
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-bagpipe] exabgp dependency

2017-05-23 Thread thomas.morin


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

2017-04-27, James Page :
On Thu, 27 Apr 2017 at 17:03 > wrote:

James Page :
I'm working on the wider networking-* packages we have in Ubuntu for 
Pike milestone 1 and noticed that exabgp is currently being pulled 
in from the master branch of exabgp; any ideas when you might be 
able to switch to a released version of exabgp?



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 one pending item he would like to cover before releasing is
having exabgp run with python3, and not everything is ready [1].

So, while I don't have a full answer on the "when", this is
reasonable information on the "how" this will happen.
I hope this can be achieved in a timeframe compatible with Pike,
and plan to spend some time helping this happen.

Once this is done, we'll also work to include exabgp in
global-requirements.


That all sounds great; I'll hold off on the first milestone for this 
package in Ubuntu for now and we can review again at the next milestone!




_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

__
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-bagpipe] exabgp dependency

2017-04-27 Thread thomas.morin


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 one pending item he would like to cover before releasing is having 
exabgp run with python3, and not everything is ready [1].


So, while I don't have a full answer on the "when", this is reasonable 
information on the "how" this will happen.
I hope this can be achieved in a timeframe compatible with Pike, and 
plan to spend some time helping this happen.


Once this is done, we'll also work to include exabgp in global-requirements.

Best,

-Thomas

[1] https://github.com/Exa-Networks/exabgp/issues/598


James Page :

Hi

I'm working on the wider networking-* packages we have in Ubuntu for 
Pike milestone 1 and noticed that exabgp is currently being pulled in 
from the master branch of exabgp; any ideas when you might be able to 
switch to a released version of exabgp?


Cheers

James


__
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




_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

__
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] work on Common Flow Classifier and OVS Agent extension for Newton cycle

2016-05-09 Thread thomas.morin


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 able to attend 
at that time.

Might 15:00 UTC work for others ?
If not, well, I'll make do with log/emails/pads/gerrit interactions.

-Thomas




-Original Message-
From: Cathy Zhang
Sent: Thursday, April 21, 2016 11:43 AM
To: Cathy Zhang; OpenStack Development Mailing List (not for usage questions); 
Ihar Hrachyshka; Vikram Choudhary; Sean M. Collins; Haim Daniel; Mathieu Rohon; 
Shaughnessy, David; Eichberger, German; Henry Fourie; arma...@gmail.com; Miguel 
Angel Ajo; Reedip; Thierry Carrez
Cc: Cathy Zhang
Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Hi everyone,

We have room 400 at 3:10pm on Thursday available for discussion of the two 
topics.
Another option is to use the common room with roundtables in "Salon C" during 
Monday or Wednesday lunch time.

Room 400 at 3:10pm is a closed room while the Salon C is a big open room which 
can host 500 people.

I am Ok with either option. Let me know if anyone has a strong preference.

Thanks,
Cathy


-Original Message-
From: Cathy Zhang
Sent: Thursday, April 14, 2016 1:23 PM
To: OpenStack Development Mailing List (not for usage questions); 'Ihar 
Hrachyshka'; Vikram Choudhary; 'Sean M. Collins'; 'Haim Daniel'; 'Mathieu 
Rohon'; 'Shaughnessy, David'; 'Eichberger, German'; Cathy Zhang; Henry Fourie; 
'arma...@gmail.com'
Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Thanks for everyone's reply!

Here is the summary based on the replies I received:

1.  We should have a meet-up for these two topics. The "to" list are the people 
who have interest in these topics.
 I am thinking about around lunch time on Tuesday or Wednesday since some 
of us will fly back on Friday morning/noon.
 If this time is OK with everyone, I will find a place and let you know 
where and what time to meet.

2.  There is a bug opened for the QoS Flow Classifier 
https://bugs.launchpad.net/neutron/+bug/1527671
We can either change the bug title and modify the bug details or start with a 
new one for the common FC which provides info on all requirements needed by all 
relevant use cases. There is a bug opened for OVS agent extension 
https://bugs.launchpad.net/neutron/+bug/1517903

3.  There are some very rough, ugly as Sean put it:-), and preliminary work on 
common FC https://github.com/openstack/neutron-classifier which we can see how 
to leverage. There is also a SFC API spec which covers the FC API for SFC usage 
https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst,
the following is the CLI version of the Flow Classifier for your reference:

neutron flow-classifier-create [-h]
 [--description ]
 [--protocol ]
 [--ethertype ]
 [--source-port :]
 [--destination-port :]
 [--source-ip-prefix ]
 [--destination-ip-prefix ]
 [--logical-source-port ]
 [--logical-destination-port ]
 [--l7-parameters ] FLOW-CLASSIFIER-NAME

The corresponding code is here 
https://github.com/openstack/networking-sfc/tree/master/networking_sfc/extensions

4.  We should come up with a formal Neutron spec for FC and another one for OVS 
Agent extension and get everyone's review and approval. Here is the etherpad 
catching our previous requirement discussion on OVS agent (Thanks David for the 
link! I remember we had this discussion before) 
https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion


More inline.

Thanks,
Cathy


-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
Sent: Thursday, April 14, 2016 3:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Cathy Zhang  wrote:


Hi everyone,
Per Armando’s request, Louis and I are looking into the following
features for Newton cycle.
· Neutron Common FC used for SFC, QoS, Tap as a service etc.,
· OVS Agent extension
Some of you might know that we already developed a FC in
networking-sfc project and QoS also has a FC. It makes sense that we
have one common FC in Neutron that could be shared by SFC, QoS, Tap as a 
service etc.
features in Neutron.

I don’t actually know of any classifier in QoS. It’s only planned to emerge, 
but there are no specs or anything specific to the feature.

Anyway, I agree that classifier API belongs to core neutron and should be 
reused by all interested subprojects from there.


Different features may extend OVS agent and add different new OVS flow
tables to support their new

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

2015-11-19 Thread thomas.morin


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 packaged in distributions along 
with the other compatible components, and it clearly tells deployers of your 
project which versions are meant to go with those other components.


Fair enough. The implicit I had in mind is the relative youth of 
networking-bgpvpn.

What you describe indeed make sense for a mature project.

Maybe what is needed is a way to accommodate with the needs of projects 
in their early days, before they evolve into a cycle release model.




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” ?

Again, it’s about signaling where your project fits into the ecosystem of other 
projects.


See above. I think some project aren't mature enough to advertise that 
they fit in the 6-month cycle release.



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).

We call them stable branches because we don’t expect them to receive a lot of 
new features.
If you depend on having the final release of neutron for a series available 
before you can finalize your project, that is indeed a new model.


This is not really the case we are in.
We could technically have targeted to do a liberty release at the same 
time as Openstack, it happens that the project hadn't yet ramped up 
quick enough to allow that (project created early June, many discussion 
on the API in July/August etc.).
So we had to accept doing a delayed release, and it means doing active 
work in a master that targets Liberty.



  But as I said in my other email, it’s not clear that’s something desirable, 
and it would be better to have the stadium projects released closer in sync 
with core neutron.


Yes, a key part of the discussion relates to whether there it is 
desirable or not to allow a project 'master' to target Openstack 
stable/x.  I will would that it does for projects that start, because it 
will help big tent projects do ramp up at their own pace.
Maybe the community will decide that this is not ok for 
x=too-old-a-release, but I would tend to think that this should be 
advertized/enforced by tagging rather than tools built-in rules.


-Thomas

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


__
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] How could an L2 agent extension access agent methods ?

2015-09-30 Thread thomas.morin

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 be named agent_context .

However, contrarily to ML2 plugin which provides a context when calling 
most driver methods, I don't think that here we would need a context to 
be passed at each call of an AgentCoreResourceExtension, providing a 
interface to hook to the agent at initialize seems enough to me.

Thanks,

-Thomas

On Fri, Sep 25, 2015 at 11:57 AM, Kevin Benton > wrote:

   I think the 4th of the options you proposed would be the best. We
   don't want to give agents direct access to the agent object or else
   we will run the risk of breaking extensions all of the time during
   any kind of reorganization or refactoring. Having a well defined API
   in between will give us flexibility to move things around.

   On Fri, Sep 25, 2015 at 1:32 AM, > wrote:

   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 implementation
   running on the compute nodes. We also need the OVS agent to
   setup specific things on the OVS bridges for MPLS traffic.

   To extend the agent behavior, we currently create a new agent by
   mimicking the main() in ovs_neutron_agent.py but instead of
   instantiating instantiate OVSAgent, with instantiate a class
   that overloads the OVSAgent class with the additional behavior
   we need [1] .

   This is really not the ideal way of extending the agent, and we
   would prefer using the L2 agent extension framework [2].

   Using the L2 agent extension framework would work, but only
   partially: it would easily allos us to register our RPC
   consumers, but not to let us access to some
   datastructures/methods of the agent that we need to use:
   setup_entry_for_arp_reply and local_vlan_map, access to the
   OVSBridge objects to manipulate OVS ports.

   I've filled-in an RFE bug to track this issue [5].

   We would like something like one of the following:
   1) augment the L2 agent extension interface
   (AgentCoreResourceExtension) to give access to the agent object
   (and thus let the extension call methods of the agent) by giving
   the agent as a parameter of the initialize method [4]
   2) augment the L2 agent extension interface
   (AgentCoreResourceExtension) to give access to the agent object
   (and thus let the extension call methods of the agent) by giving
   the agent as a parameter of a new setAgent method
   3) augment the L2 agent extension interface
   (AgentCoreResourceExtension) to give access only to
   specific/chosen methods on the agent object, for instance by
   giving a dict as a parameter of the initialize method [4], whose
   keys would be method names, and values would be pointer to these
   methods on the agent object
   4) define a new interface with methods to access things inside
   the agent, this interface would be implemented by an object
   instantiated by the agent, and that the agent would pass to the
   extension manager, thus allowing the extension manager to passe
   the object to an extension through the initialize method of
   AgentCoreResourceExtension [4]

   Any feedback on these ideas...?
   Of course any other idea is welcome...

   For the sake of triggering reaction, the question could be
   rephrased as: if we submit a change doing (1) above, would it
   have a reasonable chance of merging ?

   -Thomas

   [1]

https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/service_drivers/bagpipe/ovs_agent/ovs_bagpipe_neutron_agent.py
   [2] https://review.openstack.org/#/c/195439/
   [3]

https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py#L30
   [4]

https://github.com/openstack/neutron/blob/master/neutron/agent/l2/agent_extension.py#L28
   [5] https://bugs.launchpad.net/neutron/+bug/1499637

_

   Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
   pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
recu

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

2015-09-30 Thread thomas.morin


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.


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.


Does this approach make sense ?

-Thomas

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


__
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] How could an L2 agent extension access agent methods ?

2015-09-25 Thread thomas.morin


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 implementation running on the 
compute nodes. We also need the OVS agent to setup specific things on 
the OVS bridges for MPLS traffic.


To extend the agent behavior, we currently create a new agent by 
mimicking the main() in ovs_neutron_agent.py but instead of 
instantiating instantiate OVSAgent, with instantiate a class that 
overloads the OVSAgent class with the additional behavior we need [1] .


This is really not the ideal way of extending the agent, and we would 
prefer using the L2 agent extension framework [2].


Using the L2 agent extension framework would work, but only partially: 
it would easily allos us to register our RPC consumers, but not to let 
us access to some datastructures/methods of the agent that we need to 
use: setup_entry_for_arp_reply and local_vlan_map, access to the 
OVSBridge objects to manipulate OVS ports.


I've filled-in an RFE bug to track this issue [5].

We would like something like one of the following:
1) augment the L2 agent extension interface (AgentCoreResourceExtension) 
to give access to the agent object (and thus let the extension call 
methods of the agent) by giving the agent as a parameter of the 
initialize method [4]
2) augment the L2 agent extension interface (AgentCoreResourceExtension) 
to give access to the agent object (and thus let the extension call 
methods of the agent) by giving the agent as a parameter of a new 
setAgent method
3) augment the L2 agent extension interface (AgentCoreResourceExtension) 
to give access only to specific/chosen methods on the agent object, for 
instance by giving a dict as a parameter of the initialize method [4], 
whose keys would be method names, and values would be pointer to these 
methods on the agent object
4) define a new interface with methods to access things inside the 
agent, this interface would be implemented by an object instantiated by 
the agent, and that the agent would pass to the extension manager, thus 
allowing the extension manager to passe the object to an extension 
through the initialize method of AgentCoreResourceExtension [4]


Any feedback on these ideas...?
Of course any other idea is welcome...

For the sake of triggering reaction, the question could be rephrased as: 
if we submit a change doing (1) above, would it have a reasonable chance 
of merging ?


-Thomas

[1] 
https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/service_drivers/bagpipe/ovs_agent/ovs_bagpipe_neutron_agent.py

[2] https://review.openstack.org/#/c/195439/
[3] 
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py#L30
[4] 
https://github.com/openstack/neutron/blob/master/neutron/agent/l2/agent_extension.py#L28

[5] https://bugs.launchpad.net/neutron/+bug/1499637


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

__
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] How could an L2 agent extension access agent methods ?

2015-09-25 Thread thomas.morin


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

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.


-Thomas




Kevin Benton wrote:

I think the 4th of the options you proposed would be the best. We don't
want to give agents direct access to the agent object or else we will 
run

the risk of breaking extensions all of the time during any kind of
reorganization or refactoring. Having a well defined API in between will
give us flexibility to move things around.

On Fri, Sep 25, 2015 at 1:32 AM, wrote:


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 implementation running on the compute 
nodes.
We also need the OVS agent to setup specific things on the OVS 
bridges for

MPLS traffic.

To extend the agent behavior, we currently create a new agent by 
mimicking
the main() in ovs_neutron_agent.py but instead of instantiating 
instantiate
OVSAgent, with instantiate a class that overloads the OVSAgent class 
with

the additional behavior we need [1] .

This is really not the ideal way of extending the agent, and we would
prefer using the L2 agent extension framework [2].

Using the L2 agent extension framework would work, but only 
partially: it

would easily allos us to register our RPC consumers, but not to let us
access to some datastructures/methods of the agent that we need to use:
setup_entry_for_arp_reply and local_vlan_map, access to the OVSBridge
objects to manipulate OVS ports.

I've filled-in an RFE bug to track this issue [5].

We would like something like one of the following:
1) augment the L2 agent extension interface 
(AgentCoreResourceExtension)
to give access to the agent object (and thus let the extension call 
methods
of the agent) by giving the agent as a parameter of the initialize 
method

[4]
2) augment the L2 agent extension interface 
(AgentCoreResourceExtension)
to give access to the agent object (and thus let the extension call 
methods
of the agent) by giving the agent as a parameter of a new setAgent 
method
3) augment the L2 agent extension interface 
(AgentCoreResourceExtension)

to give access only to specific/chosen methods on the agent object, for
instance by giving a dict as a parameter of the initialize method [4],
whose keys would be method names, and values would be pointer to these
methods on the agent object
4) define a new interface with methods to access things inside the 
agent,
this interface would be implemented by an object instantiated by the 
agent,
and that the agent would pass to the extension manager, thus 
allowing the

extension manager to passe the object to an extension through the
initialize method of AgentCoreResourceExtension [4]

Any feedback on these ideas...?
Of course any other idea is welcome...

For the sake of triggering reaction, the question could be rephrased 
as:
if we submit a change doing (1) above, would it have a reasonable 
chance of

merging ?

-Thomas

[1]
https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/service_drivers/bagpipe/ovs_agent/ovs_bagpipe_neutron_agent.py 


[2] https://review.openstack.org/#/c/195439/
[3]
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py#L30 


[4]
https://github.com/openstack/neutron/blob/master/neutron/agent/l2/agent_extension.py#L28 


[5] https://bugs.launchpad.net/neutron/+bug/1499637

_ 



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous 
avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration,
Orange

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

2015-07-27 Thread thomas.morin


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 
networking-bgpvpn project.Don't hesitate to have a look if you are a 
Telco and needs to interconnect your BGP-based VPNs with Openstack.


Apologies again,

-Thomas




Le 24/07/2015 17:40, thomas.mo...@orange.com a écrit :

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

-Thomas






















_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

__
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] talk proposal for Tokyo Summit: Interconnecting Neutron and BGP-based operator VPNs

2015-07-24 Thread thomas.morin


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 
http://email.openstack.org/wf/click?upn=KDXUwHsqj2QOekTYbWDSGOQec3b75Fovt3HVvm3PiyFsTeh9f03Hig50WTaMW6Vh9UXoSwNRuH08K4E0EcoOIkw4vHH2-2B8q1HiFESJ3lLmkd-2Bmh4RS9dNB-2BTdYVxI1o-2B_kO8kwhiD9hOkVQT6GsYQuqzD-2BTRmjelSvRh14-2FBDsNUKycmEvJ3wlDJ2ugmCO1hpAbo3k8ynzRCdVbeYMbiI6byGrOEMxCU17MpoT-2Btn6xqAUoFEMDsvEdYIxpmTrG9OmLbYunZTqdQAZcFHfntocgDpA7SM6SaQoh-2FeQtCCzdVcvX9vJpjrDc7S4G-2F-2FL2-2ByO6qIswAXtNNW8iVX3QW-2FC5nO4L90E-2Bw0UQHwu4o0ADiTpOPiBsQlRyfevNQmorduMkJuUi7yb59g7pJqIbVzaCCsIpDEL7hfzqaTujaaziIUw0NIz66BFodl9dFboSuLvG-2FH88234duhIW0ycMwdlN0DjQi7PFYQGQmLWmeoeyZhau0OWEyEsWxOT0a-2F4NMnZBZ87mTXb8Mcm8a4MJK6yg-3D-3D


-Thomas

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

__
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][bgpvpn] IRC meetings on BGP VPN interconnection API

2015-06-01 Thread thomas.morin


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 networking-bgpvpn stackforge project, 
so we'll use the 15:00 UTC slot on #openstack-alt for this purpose (free 
AFAICT). And, we will encourage all participants to attend the VPNaaS 
meeting right after, on #openstack-meeting-3.


Thank you,

-Thomas


Le 01/06/2015 13:06, Paul Michali a écrit :

FYI, the channel is openstack-meeting-3.

On Sun, May 31, 2015 at 10:41 PM Mohammad Hanif mha...@brocade.com 
mailto:mha...@brocade.com wrote:


Hi Thomas,

The time reserved for the weekly IRC is 1600 UTC on Tuesdays
(http://eavesdrop.openstack.org/#Neutron_VPNaaS_Meeting). The IRC
channel might not be available on any other time (1500 UTC is
taken by the libvirt team meeting).

Thanks,
—Hanif.



On 5/29/15, 12:57 PM, Vikram Choudhary viks...@gmail.com
mailto:viks...@gmail.com wrote:

Hi Thomas/Mathieu,

Thanks for starting this mail thread. Let's discuss over the IRC as
suggested by Paul.

Thanks
Vikram

On 5/29/15, Paul Michali p...@michali.net mailto:p...@michali.net
wrote:
 You can use the VPNaaS IRC channel/time... we don't have much
on the agenda
 right now, other than discussion VPN flavors for Liberty, in
which it would
 be good to discuss BGP VPN and Edge VPN.

 Regards,

 Paul Michali (pc_m)

 On Fri, May 29, 2015 at 11:08 AM thomas.mo...@orange.com
mailto:thomas.mo...@orange.com wrote:

 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
implementation+drivers
 [2].

 The slot we propose is ** Tuesday 15:00 UTC ** with the first
meeting
 next Tuesday (June 2nd).

 Note that, based on last week feedback, we submitted the existing
 stackforge project for inclusion in the Neutron big tent
earlier this
 week [3].

 We will do a proper meeting registration (patch to openstack-infra
 irc-meeting) and send meeting info with wiki and meeting room
before
 next Tuesday.

 Looking forward to discussing with everyone interested!

 -Thomas  Mathieu

 [1] currently being discussed at
https://review.openstack.org/#/c/177740
 [2] https://github.com/stackforge/networking-bgpvpn
 [3] https://review.openstack.org/#/c/186041






_

 Ce message et ses pieces jointes peuvent contenir des informations
 confidentielles ou privilegiees et ne doivent donc
 pas etre diffuses, exploites ou copies sans autorisation. Si
vous avez
 recu ce message par erreur, veuillez le signaler
 a l'expediteur et le detruire ainsi que les pieces jointes.
Les messages
 electroniques etant susceptibles d'alteration,
 Orange decline toute responsabilite si ce message a ete
altere, deforme
 ou
 falsifie. Merci.

 This message and its attachments may contain confidential or
privileged
 information that may be protected by law;
 they should not be distributed, used or copied without
authorisation.
 If you have received this email in error, please notify the
sender and
 delete this message and its attachments.
 As emails may be altered, Orange is not liable for messages
that have
 been
 modified, changed or falsified.
 Thank you.



__
 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



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

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

2015-06-01 Thread thomas.morin


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


2015-05-29, Thomas Morin:

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 implementation+drivers
[2].

The slot we propose is ** Tuesday 15:00 UTC ** with the first meeting
next Tuesday (June 2nd).

Note that, based on last week feedback, we submitted the existing
stackforge project for inclusion in the Neutron big tent earlier this
week [3].

We will do a proper meeting registration (patch to openstack-infra
irc-meeting) and send meeting info with wiki and meeting room before
next Tuesday.

Looking forward to discussing with everyone interested!

-Thomas  Mathieu

[1] currently being discussed at https://review.openstack.org/#/c/177740
[2] https://github.com/stackforge/networking-bgpvpn
[3] https://review.openstack.org/#/c/186041





_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


__
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][bgpvpn] IRC meetings on BGP VPN interconnection API

2015-05-29 Thread thomas.morin


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 implementation+drivers 
[2].


The slot we propose is ** Tuesday 15:00 UTC ** with the first meeting 
next Tuesday (June 2nd).


Note that, based on last week feedback, we submitted the existing 
stackforge project for inclusion in the Neutron big tent earlier this 
week [3].


We will do a proper meeting registration (patch to openstack-infra 
irc-meeting) and send meeting info with wiki and meeting room before 
next Tuesday.


Looking forward to discussing with everyone interested!

-Thomas  Mathieu

[1] currently being discussed at https://review.openstack.org/#/c/177740
[2] https://github.com/stackforge/networking-bgpvpn
[3] https://review.openstack.org/#/c/186041



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


__
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][L3] BGP Dynamic Routing Proposal

2014-06-24 Thread thomas.morin

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 dataplane driver, 
but for now, having just a VXLAN driver is fine enough for intra-DC use cases.

(to what current BGP solution do you want to compare with?)

 What you are thinking (if I am right) is something like this below which is 
 traditional deployment model of E-VPN solution.

I see your point, inter-DC would also be addressable with E-VPN, combined or 
not with other techniques.

 https://tools.ietf.org/html/draft-rabadan-l2vpn-dci-evpn-overlay-01#ref-EVPN-Overlays

The above describe ways, among others, to do inter-DC.

 But what I was thinking is something like PW(pseudo wire) right from CN node 
 itself, so that there will not be any breakage/stitching/mapping related 
 issue.

Sorry, but I don't get your point yet:
- what problem are you trying to solve here?
- what motivation to introduce PWs?

[...]

 If we are not thinking of starting MPLS from CNs I think existing BGP (which 
 is underway) will  be sufficient.

(Again, I'm not sure which use of BGP you are referring to above.)

Just to be 100% clear: starting an MPLS encap (or VXLAN) from CNs, based on BGP 
VPN routes, *is* a scenario we favor here.

Best,

-Thomas

 -Original Message-
 From: Thomas Morin [mailto:tmmorin.ora...@gmail.com] On Behalf Of Thomas Morin
 Sent: Monday, June 23, 2014 7:25 PM
 To: A, Keshava; OpenStack Dev
 Subject: Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal

  

 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

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

2014-06-16 Thread thomas.morin

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 architecture to 
drive a dataplane (e.g. OpenVSwtich).  It is based on an internal 
development we did to address IaaS/IP VPN interconnection issues; 
although still young the project was the basis for a few working lab 
prototypes.  There is more info in the README.

I filled-in a column for BaGPipe on the wiki page ( 
https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison ), to give 
an idea where it stands, and let people think how that could address 
needs in Openstack.  I also added a line to specify support for 
Route-Target-constrained distribution of VPN routes (RFC4684), because 
it is a real need beyond VPNv4/v6 routes for some VPN interconnection 
use deployments.

Best,

-Thomas


Nachi Ueno :
 Hi folks

 ExaBGP won't suit for BGPVPN implementation because it isn't support vpnv4.
 Ryu is supporting it, however they have no internal api to binding
 neutron network  route target.
 so I think contrail is a only solution for  BGPVPN implementation now.



 2014-05-30 2:22 GMT-07:00 Mathieu Rohon mathieu.ro...@gmail.com:
 Hi,

 I was about mentionning ExaBGP too! can we also consider using those
 BGP speakers for BGPVPN implementation [1].
 This would be consistent to have the same BGP speaker used for every
 BGP needs inside Neutron.

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


 On Fri, May 30, 2014 at 10:54 AM, Jaume Devesa devv...@gmail.com wrote:
 Hello Takashi,

 thanks for doing this! As we have proposed ExaBgp[1] in the Dynamic Routing
 blueprint[2], I've added a new column for this speaker in the wiki page. I
 plan to fill it soon.

 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.

 [1]: https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison
 [2]: https://review.openstack.org/#/c/90833/

 Regards,


 On 29 May 2014 18:42, YAMAMOTO Takashi yamam...@valinux.co.jp wrote:
 as per discussions on l3 subteem meeting today, i started
 a bgp speakers comparison wiki page for this bp.

 https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison

 Artem, can you add other requirements as columns?

 as one of ryu developers, i'm naturally biased to ryu bgp.
 i appreciate if someone provides more info for other bgp speakers.

 YAMAMOTO Takashi

 Good afternoon Neutron developers!

 There has been a discussion about dynamic routing in Neutron for the
 past few weeks in the L3 subteam weekly meetings. I've submitted a review
 request of the blueprint documenting the proposal of this feature:
 https://review.openstack.org/#/c/90833/. If you have any feedback or
 suggestions for improvement, I would love to hear your comments and 
 include
 your thoughts in the document.

 Thank you.

 Sincerely,
 Artem Dmytrenko


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

25 matches

Site Navigation

Mail list logo

Footer information