Re: [openstack-dev] [neutron][linux bridge]

2016-07-08 Thread Sławek Kapłoński
Hello,

What about tc_lib.py and function to set bandwidth limits which
linuxbridge agent is currently using?

-- 
Best regards / Pozdrawiam
Sławek Kapłoński
sla...@kaplonski.pl

On Thu, 07 Jul 2016, Bhatia, Manjeet S wrote:

> Hi,
> 
> There is work in progress for pure python driven linux network configuration. 
> I think most
> of work will be done with this patch https://review.openstack.org/#/c/155631/ 
> . The only
> thing left after this will be linux bridge configuration, Which I would like 
> to discuss with
> community. There are two ways at the moment I can think to do that 
> implementation,
> First, use pybrctl which may need some changes in library itself in order for 
> full support.
> It will clean up the code from neutron. But looking pybrctl code which is 
> just executing
> Shell commands, another solution which Brandon Logan discussed is move the 
> existing
> Code for executing those commands to neutron-lib, which I think is better 
> solution. I would
> like to have views of community, especially people working neutron-lib about 
> moving
> python code for executing brctl commands to neutron-lib.
> 
> 
> Thanks and Regards !
> Manjeet Singh Bhatia

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



signature.asc
Description: Digital signature
__
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][linux bridge]

2016-07-08 Thread Édouard Thuleau
Hi,

I'm not close to Neutron's discussions but do you think to have a look at
pyroute2 [1]?
"Pyroute2 is a pure Python netlink and Linux network configuration library.
It requires only Python stdlib, no 3rd party libraries."
Which permits to create bridge and adding interfaces easily [2] (but not
only...).

[1] https://github.com/svinota/pyroute2
[2]
https://github.com/svinota/pyroute2/blob/a76d2efd8966ec5b6cc713dc5d909b5cd070a9a8/benchmark/ipdb.py#L16

On Fri, Jul 8, 2016 at 8:05 AM, Brandon Logan 
wrote:

> pybrctl repo is at: https://github.com/udragon/pybrctl
> It is in pypi.
>
> Looks like a wrapper around the shell brctl commands.  I don't think it
> would buy us anything more than what moving neutron's current
> implementation of doing brctl commands to neutron-lib would do.  In
> fact, it might end up costing more.  That's just my very uninformed
> opinion though.
>
> Thanks,
> Brandon
>
> On Thu, 2016-07-07 at 23:59 +, Bhatia, Manjeet S wrote:
> > Hi,
> >
> > There is work in progress for pure python driven linux network
> > configuration. I think most
> > of work will be done with this patch https://review.openstack.org/#/c
> > /155631/ . The only
> > thing left after this will be linux bridge configuration, Which I
> > would like to discuss with
> > community. There are two ways at the moment I can think to do that
> > implementation,
> > First, use pybrctl which may need some changes in library itself in
> > order for full support.
> > It will clean up the code from neutron. But looking pybrctl code
> > which is just executing
> > Shell commands, another solution which Brandon Logan discussed is
> > move the existing
> > Code for executing those commands to neutron-lib, which I think is
> > better solution. I would
> > like to have views of community, especially people working neutron-
> > lib about moving
> > python code for executing brctl commands to neutron-lib.
> >
> >
> > Thanks and Regards !
> > Manjeet Singh Bhatia
> __
> 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][linux bridge]

2016-07-08 Thread Brandon Logan
pybrctl repo is at: https://github.com/udragon/pybrctl
It is in pypi.

Looks like a wrapper around the shell brctl commands.  I don't think it
would buy us anything more than what moving neutron's current
implementation of doing brctl commands to neutron-lib would do.  In
fact, it might end up costing more.  That's just my very uninformed
opinion though.

Thanks,
Brandon

On Thu, 2016-07-07 at 23:59 +, Bhatia, Manjeet S wrote:
> Hi,
>  
> There is work in progress for pure python driven linux network
> configuration. I think most
> of work will be done with this patch https://review.openstack.org/#/c
> /155631/ . The only
> thing left after this will be linux bridge configuration, Which I
> would like to discuss with
> community. There are two ways at the moment I can think to do that
> implementation,
> First, use pybrctl which may need some changes in library itself in
> order for full support.
> It will clean up the code from neutron. But looking pybrctl code
> which is just executing
> Shell commands, another solution which Brandon Logan discussed is
> move the existing
> Code for executing those commands to neutron-lib, which I think is
> better solution. I would
> like to have views of community, especially people working neutron-
> lib about moving
> python code for executing brctl commands to neutron-lib.
>  
>  
> Thanks and Regards !
> Manjeet Singh Bhatia
__
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][linux bridge]

2016-07-07 Thread Bhatia, Manjeet S
Hi,

There is work in progress for pure python driven linux network configuration. I 
think most
of work will be done with this patch https://review.openstack.org/#/c/155631/ . 
The only
thing left after this will be linux bridge configuration, Which I would like to 
discuss with
community. There are two ways at the moment I can think to do that 
implementation,
First, use pybrctl which may need some changes in library itself in order for 
full support.
It will clean up the code from neutron. But looking pybrctl code which is just 
executing
Shell commands, another solution which Brandon Logan discussed is move the 
existing
Code for executing those commands to neutron-lib, which I think is better 
solution. I would
like to have views of community, especially people working neutron-lib about 
moving
python code for executing brctl commands to neutron-lib.


Thanks and Regards !
Manjeet Singh Bhatia
__
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] Linux Bridge CI is now a voting gate job

2015-12-09 Thread Jay Pipes

On 12/08/2015 07:54 PM, Andreas Scheuring wrote:

Great work!


Indeed, Sean, fantastic effort getting this done. :)

-jay

On Mo, 2015-12-07 at 21:05 +, Sean M.

Collins wrote:

>It's been a couple months - the last time I posted on this subject we
>were still working on getting Linux Bridge to become an experimental[1]
>job. During the Liberty cycle, the Linux Bridge CI was promoted from
>experimental status, to being run on all Neutron changes, but
>non-voting.
>
>Well, we're finally at the point where the Linux Bridge job is
>gating[2]. I am sure there are still bugs that will need to be addressed
>- I will be watching the gate very carefully the next couple of hours
>and throughout this week.
>
>Feel free to leave bags of flaming :poo: at my doorstep
>
>On a serious note, thank you to everyone who over this year has
>committed patches and fixes to make this happen, it's been an amazing
>example of open source and community involvement. I'll be happy to buy
>drinks if you helped with LB in San Antonio if there is a neutron social
>event (in addition to paying back amotoki for the Tokyo social).
>
>[1]:http://lists.openstack.org/pipermail/openstack-dev/2015-July/068859.html
>[2]:https://review.openstack.org/205674
>


__
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] Linux Bridge CI is now a voting gate job

2015-12-09 Thread Sean Dague
On 12/07/2015 04:05 PM, Sean M. Collins wrote:
> It's been a couple months - the last time I posted on this subject we
> were still working on getting Linux Bridge to become an experimental[1]
> job. During the Liberty cycle, the Linux Bridge CI was promoted from
> experimental status, to being run on all Neutron changes, but
> non-voting.
> 
> Well, we're finally at the point where the Linux Bridge job is
> gating[2]. I am sure there are still bugs that will need to be addressed
> - I will be watching the gate very carefully the next couple of hours
> and throughout this week.
> 
> Feel free to leave bags of flaming :poo: at my doorstep
> 
> On a serious note, thank you to everyone who over this year has
> committed patches and fixes to make this happen, it's been an amazing
> example of open source and community involvement. I'll be happy to buy
> drinks if you helped with LB in San Antonio if there is a neutron social
> event (in addition to paying back amotoki for the Tokyo social).
> 
> [1]: http://lists.openstack.org/pipermail/openstack-dev/2015-July/068859.html
> [2]: https://review.openstack.org/205674
> 

Nicely done! Thanks much!

-Sean

-- 
Sean Dague
http://dague.net

__
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] Linux Bridge CI is now a voting gate job

2015-12-09 Thread Armando M.
On 9 December 2015 at 03:53, Sean Dague  wrote:

> On 12/07/2015 04:05 PM, Sean M. Collins wrote:
> > It's been a couple months - the last time I posted on this subject we
> > were still working on getting Linux Bridge to become an experimental[1]
> > job. During the Liberty cycle, the Linux Bridge CI was promoted from
> > experimental status, to being run on all Neutron changes, but
> > non-voting.
> >
> > Well, we're finally at the point where the Linux Bridge job is
> > gating[2]. I am sure there are still bugs that will need to be addressed
> > - I will be watching the gate very carefully the next couple of hours
> > and throughout this week.
> >
> > Feel free to leave bags of flaming :poo: at my doorstep
> >
> > On a serious note, thank you to everyone who over this year has
> > committed patches and fixes to make this happen, it's been an amazing
> > example of open source and community involvement. I'll be happy to buy
> > drinks if you helped with LB in San Antonio if there is a neutron social
> > event (in addition to paying back amotoki for the Tokyo social).
> >
> > [1]:
> http://lists.openstack.org/pipermail/openstack-dev/2015-July/068859.html
> > [2]: https://review.openstack.org/205674
> >
>
> Nicely done! Thanks much!
>

Don't want to be a party pooper but I added the job failure rate to the
dashboard [1], and the result so far is not pleasing. Hopefully this is due
to a failure tail fixed in [2].

Cheers,
Armando

[1] https://review.openstack.org/#/c/255588/
[2] https://review.openstack.org/#/c/252493/


> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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] Linux Bridge CI is now a voting gate job

2015-12-08 Thread Andreas Scheuring
Great work!
-- 
Andreas
(IRC: scheuran)



On Mo, 2015-12-07 at 21:05 +, Sean M. Collins wrote:
> It's been a couple months - the last time I posted on this subject we
> were still working on getting Linux Bridge to become an experimental[1]
> job. During the Liberty cycle, the Linux Bridge CI was promoted from
> experimental status, to being run on all Neutron changes, but
> non-voting.
> 
> Well, we're finally at the point where the Linux Bridge job is
> gating[2]. I am sure there are still bugs that will need to be addressed
> - I will be watching the gate very carefully the next couple of hours
> and throughout this week.
> 
> Feel free to leave bags of flaming :poo: at my doorstep
> 
> On a serious note, thank you to everyone who over this year has
> committed patches and fixes to make this happen, it's been an amazing
> example of open source and community involvement. I'll be happy to buy
> drinks if you helped with LB in San Antonio if there is a neutron social
> event (in addition to paying back amotoki for the Tokyo social).
> 
> [1]: http://lists.openstack.org/pipermail/openstack-dev/2015-July/068859.html
> [2]: https://review.openstack.org/205674
> 


__
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] Linux Bridge CI is now a voting gate job

2015-12-07 Thread Sean M. Collins
It's been a couple months - the last time I posted on this subject we
were still working on getting Linux Bridge to become an experimental[1]
job. During the Liberty cycle, the Linux Bridge CI was promoted from
experimental status, to being run on all Neutron changes, but
non-voting.

Well, we're finally at the point where the Linux Bridge job is
gating[2]. I am sure there are still bugs that will need to be addressed
- I will be watching the gate very carefully the next couple of hours
and throughout this week.

Feel free to leave bags of flaming :poo: at my doorstep

On a serious note, thank you to everyone who over this year has
committed patches and fixes to make this happen, it's been an amazing
example of open source and community involvement. I'll be happy to buy
drinks if you helped with LB in San Antonio if there is a neutron social
event (in addition to paying back amotoki for the Tokyo social).

[1]: http://lists.openstack.org/pipermail/openstack-dev/2015-July/068859.html
[2]: https://review.openstack.org/205674

-- 
Sean M. Collins

__
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] Linux Bridge CI status report

2015-07-27 Thread Sean M. Collins
As of Jul 27 2015 - we are currently passing 85% of the time on the LB
CI job. There are some legitimate failures on patches where LB was the
dissenting job, meaning there was most likely a bug in the LB code or
job. I've listed the runs where the Linux Bridge CI job under L32 of
this etherpad - I plan to drill down into the logs and see if we can
classify the failures.

https://etherpad.openstack.org/p/devstack-linuxbridge

Basically the 85% stat is for just today since the 48 hour query in
Kibana includes the weekend, where not a lot of traffic occurs - however
using a small sample allows me to filter the failures by hand, and
classify patches that failed multiple CI jobs, meaning the patch was
probably flawed, versus patches that *should* have passed the LB CI.

Also, I have backported some DevStack patches to the stable/kilo branch to
enable the Linux Bridge CI job to successfully run on patches against
that branch, which has improved the overall success rate since there
were recently patches against stable/kilo due to an upcoming 
release.

Ideally, I'd like to see the following backport approved, however I
don't think it warrants a freeze exception.

https://review.openstack.org/202845

Also, if we could get some core reviewers to look at the following, it
would be much appreciated.

https://review.openstack.org/193485

Overall, I'm very happy with the stats so far, and have a WIP patch to
make the LB job voting. I think after we get 202845 merged and maybe get
up into the 90% success rate I'll take off the WIP and solicit feedback

https://review.openstack.org/205674


-- 
Sean M. Collins

__
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] Linux Bridge CI status report

2015-07-08 Thread Kyle Mestery
This is great work! I see most of the devstack patches have now merged, and
the Neutron ones are merging to.

On Wed, Jul 8, 2015 at 5:37 AM, Sean Dague s...@dague.net wrote:

 Nice job all! Really awesome. I just approved 195653, so it will show up
 in the check queue non voting shortly.

 -Sean

 On 07/07/2015 10:01 PM, Sean M. Collins wrote:
  Hi,
 
  At the risk of jinxing it, I'd like to report that with the merge of a
  couple patches to fix race conditions[1][2] and DevStack[3] - we're
 looking
  at promising results for experimental runs for the Linux Bridge
  CI on changes that are supposed to pass[4], as well as being useful for
  patches under development[5][6].
 
  It's still early, but I think we've made great progress so far, and my
  plan is in the next week or so to see if we can move it from
  experimental status, to the check queue (but keep it non-voting)[7].
 This will
  help uncover any other bugs that exist, as well as helping provide a CI
 system
  that can help give certainty for reviewers on patches
  to Neutron in the Linux Bridge parts of the tree.
 
  I'd also like to thank the bug reporters and authors of
  of the linked patches - since most of what I did was just nudge
  things along.
 
  [1]: https://review.openstack.org/#/c/198833/
 
  [2]: https://review.openstack.org/#/c/197162/
 
  [3]: https://review.openstack.org/#/c/192906/
 
  [4]: https://review.openstack.org/#/c/187235/
 
  [5]: https://review.openstack.org/196986
 
  [6]: https://review.openstack.org/#/c/138512/
 
  [7]: https://review.openstack.org/#/c/195653/
 


 --
 Sean Dague
 http://dague.net

 __
 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] Linux Bridge MTU bug when the VXLAN tunneling is used

2013-10-21 Thread Édouard Thuleau
I had a look for fix that and I don't found a simple way.

The minimal MTU can be deducted by the LB agent with the value found on the
bridge and the LB agent can set it on veth interface connect to that bridge.
But there no easy way to set it on the other side of the veth in the
namespace. LB agent doesn't know the name of the other side of the veth and
it doesn't know the name of the namespace. Furthermore, I'm not sure it's a
good way to modify network in a namespace doesn't manage by the LB agent.

Another simple solution, is to set a global config flag to define the
minimal MTU and all agents which create veth use it to set interfaces MTU.

I opened a bug to discuss: https://bugs.launchpad.net/neutron/+bug/1242534

Regards,
Édouard.


On Sun, Oct 20, 2013 at 5:29 PM, Salvatore Orlando sorla...@nicira.comwrote:

 It might be worth both documenting this limitation on the admin guide and
 provide a fix which we should backport to havana too.
 It sounds like the fix should not be too extensive, so the backport should
 be easily feasible.

 Regards,
 Salvatore


 On 18 October 2013 21:50, Édouard Thuleau thul...@gmail.com wrote:

 Hi all,

 I made some tests with the ML2 plugin and the Linux Bridge agent with
 VXLAN tunneling.

 By default, physical interface (used for VXLAN tunneling) has an MTU of
 1500 octets. And when LB agent creates a VXLAN interface, the MTU is
 automatically 50 octets less than the physical interface (so 1450 octets)
 [1]. Therefore, the bridge use to plug tap of VM, veth from network
 namespaces (l3 or dhcp) and VXLAN interface has an MTU of 1450 octets
 (Linux bridges take minimum of all the underlying ports [2]).

 So the bridge could only forward packets of length smaller than 1450
 octets to VXLAN interface [3].

 But the veth interfaces used to link network namespaces and bridges are
 spawn by l3 and dhcp agents (and perhaps other agents) with an MTU of 1500
 octets. So, packets which arriving from them are dropped if they need to be
 forwarded to the VXLAN interface.

 A simple workaround is to increase by 50 at least the MTU of the physical
 interface to harmonize MTU between interfaces. But by default (without MTU
 customizing), the LB/VXLAN mode have strange behavior (cannot make curl
 from server behind a router or execute command with verbose output in SSH
 through a floating IP (SSH connection works)...)

 So my question is, do you think we need to open a bug and find a fix for
 that ? Or do we need to put warning in docs (and logs perhaps)?

 [1]
 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/vxlan.c#n2437
 [2]
 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/bridge/br_if.c#n402
 [3]
 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/bridge/br_forward.c#n74

 Édouard.

 ___
 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


Re: [openstack-dev] [Neutron] Linux Bridge MTU bug when the VXLAN tunneling is used

2013-10-20 Thread Salvatore Orlando
It might be worth both documenting this limitation on the admin guide and
provide a fix which we should backport to havana too.
It sounds like the fix should not be too extensive, so the backport should
be easily feasible.

Regards,
Salvatore


On 18 October 2013 21:50, Édouard Thuleau thul...@gmail.com wrote:

 Hi all,

 I made some tests with the ML2 plugin and the Linux Bridge agent with
 VXLAN tunneling.

 By default, physical interface (used for VXLAN tunneling) has an MTU of
 1500 octets. And when LB agent creates a VXLAN interface, the MTU is
 automatically 50 octets less than the physical interface (so 1450 octets)
 [1]. Therefore, the bridge use to plug tap of VM, veth from network
 namespaces (l3 or dhcp) and VXLAN interface has an MTU of 1450 octets
 (Linux bridges take minimum of all the underlying ports [2]).

 So the bridge could only forward packets of length smaller than 1450
 octets to VXLAN interface [3].

 But the veth interfaces used to link network namespaces and bridges are
 spawn by l3 and dhcp agents (and perhaps other agents) with an MTU of 1500
 octets. So, packets which arriving from them are dropped if they need to be
 forwarded to the VXLAN interface.

 A simple workaround is to increase by 50 at least the MTU of the physical
 interface to harmonize MTU between interfaces. But by default (without MTU
 customizing), the LB/VXLAN mode have strange behavior (cannot make curl
 from server behind a router or execute command with verbose output in SSH
 through a floating IP (SSH connection works)...)

 So my question is, do you think we need to open a bug and find a fix for
 that ? Or do we need to put warning in docs (and logs perhaps)?

 [1]
 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/vxlan.c#n2437
 [2]
 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/bridge/br_if.c#n402
 [3]
 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/bridge/br_forward.c#n74

 Édouard.

 ___
 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