Re: [openstack-dev] [neutron] when icehouse will be frozen

Ok My previous answer was actually about the Feature proposal freeze which happened two days ago. Cheers, Miguel Ángel. On 02/20/2014 11:27 AM, Thierry Carrez wrote: 马煜 wrote: who know when to freezy icehouse version ? my bp on ml2 driver has been approved, code is under review, but I have s

[openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

Hello, Recently, I found a serious issue about network-nodes startup time, neutron-rootwrap eats a lot of cpu cycles, much more than the processes it's wrapping itself. On a database with 1 public network, 192 private networks, 192 routers, and 192 nano VMs, with OVS plugin: N

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

On 03/06/2014 07:57 AM, IWAMOTO Toshihiro wrote: At Wed, 05 Mar 2014 15:42:54 +0100, Miguel Angel Ajo wrote: 3) I also find 10 minutes a long time to setup 192 networks/basic tenant structures, I wonder if that time could be reduced by conversion of system process calls into system library

Re: [openstack-dev] [oslo][neutron][rootwrap] Performance considerations, sudo?

ly Ross, I haven't tried cython, but I will check it in a few minutes. Iwamoto Toshihiro, Thanks for pointing us to "ip netns exec" too, I wonder if that's releated to the iproute upstream change Rick Jones was talking about. Cheers, Miguel Ángel. On 03/06/2014 09:31

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

I thought of this option, but didn't consider it, as It's somehow risky to expose an RPC end executing priviledged (even filtered) commands. If I'm not wrong, once you have credentials for messaging, you can send messages to any end, even filtered, I somehow see this as a higher risk option. An

Re: [openstack-dev] [Neutron] Developer documentation

Good work on the documentation, it's something that will really help new neutron developers. On 03/07/2014 07:44 PM, Akihiro Motoki wrote: Hi Carl, I really appreciate you for writing this up! I have no hurdle to remove my -1 for the review. I just thought it is an item easy to fix. It is a

Re: [openstack-dev] [Neutron][L3] FFE request: L3 HA VRRP

+1 I Agree on this topic: experimental, and disabled-by-default if there's low impact when the functionality is disabled. On 03/07/2014 05:29 PM, Carl Baldwin wrote: +1 On Fri, Mar 7, 2014 at 2:42 AM, Édouard Thuleau wrote: +1 I though it must merge as experimental for IceHouse, to let the

Re: [openstack-dev] [Neutron][L3] FFE request: L3 HA VRRP

+1 (Voting here to workaround my previous top-posting). On 03/09/2014 01:22 PM, Nir Yechiel wrote: +1 I see it as one of the main current gaps and I believe that this is something that can promote Neutron as stable and production ready. Based on Édouard's comment below, having this enabled in

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

ests. This seems like a reasonably sensible idea to me. Yes, you're right. On 07/03/14 12:52, Miguel Angel Ajo wrote: I thought of this option, but didn't consider it, as It's somehow risky to expose an RPC end executing priviledged (even filtered) com

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

imple call to system happening, I think that'd help my understanding. Best regards, Miguel Ángel. On 03/13/2014 07:42 AM, Yuriy Taraday wrote: On Mon, Mar 10, 2014 at 3:26 PM, Miguel Angel Ajo mailto:majop...@redhat.com>> wrote: I'm not familiar with unix domain sockets

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

thing to do for ice house would probably be to run the initial sync in parallel like the dhcp-agent does for this exact reason. See: https://review.openstack.org/#/c/28914/ which did this for thr dhcp-agent. Best, Aaron On Thu, Mar 13, 2014 at 12:18 PM, Miguel Angel Ajo mailto:majop...@redh

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

eutron as 'ajo'. Best regards, Miguel Ángel. [1] https://github.com/mangelajo/shedskin.rootwrap On 03/18/2014 12:48 AM, Joe Gordon wrote: On Tue, Mar 11, 2014 at 1:46 AM, Miguel Angel Ajo Pelayo mailto:mangel...@redhat.com>> wrote: I have included on the etherpad,

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

odules implemented for shedkin. On 03/18/2014 09:14 AM, Miguel Angel Ajo wrote: Hi Joe, thank you very much for the positive feedback, I plan to spend a day during this week on the shedskin-compatibility for rootwrap (I'll branch it, and tune/cut down as necessary) to make it compile under

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

On 03/19/2014 10:54 PM, Joe Gordon wrote: On Wed, Mar 19, 2014 at 9:25 AM, Miguel Angel Ajo mailto:majop...@redhat.com>> wrote: An advance on the changes that it's requiring to have a py->c++ compiled rootwrap as a mitigation POC for havana/icehouse. http

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

Wow Yuriy, amazing and fast :-), benchmarks included ;-) The daemon solution only adds 4.5ms, good work. I'll add some comments in a while. Recently I talked with another engineer in Red Hat (working in ovirt/vdsm), and they have something like this daemon, and they are using BaseMan

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

On 03/20/2014 12:32 PM, Monty Taylor wrote: On 03/20/2014 05:31 AM, Miguel Angel Ajo wrote: On 03/19/2014 10:54 PM, Joe Gordon wrote: On Wed, Mar 19, 2014 at 9:25 AM, Miguel Angel Ajo mailto:majop...@redhat.com>> wrote: An advance on the changes that it's requirin

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

On 03/21/2014 10:42 AM, Thierry Carrez wrote: Yuriy Taraday wrote: On Thu, Mar 20, 2014 at 5:41 PM, Miguel Angel Ajo mailto:majop...@redhat.com>> wrote: If this coupled to neutron in a way that it can be accepted for Icehouse (we're killing a performance bug), or th

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

On 03/21/2014 11:01 AM, Thierry Carrez wrote: Yuriy Taraday wrote: Benchmark included showed on my machine these numbers (average over 100 iterations): Running 'ip a': ip a : 4.565ms sudo ip a : 13.744

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

It's the first call starting the daemon / loading config files, etc?, May be that first sample should be discarded from the mean for all processes (it's an outlier value). On 03/21/2014 05:32 PM, Yuriy Taraday wrote: On Fri, Mar 21, 2014 at 2:01 PM, Thierry Carrez mailto:thie...@openstack

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

It actually affects all numbers but mean (e.g. deviation is gross). Carl is right, I thought of it later in the evening, when the timeout mechanism is in place we must consider the number. I'd say keep it in there. +1 I agree. Carl On Mon, Mar 24, 2014 at 2:04 AM, Miguel

Re: [openstack-dev] [neutron]Performance of security group

st 1 spec (for 1 & 2) is going be safer for juno-* approval, then we can incorporate my spec in yours, but then "add-ipset-to-security" is not a good spec title to put all this together. Best regards, Miguel Ángel. On 07/02/2014 03:37 AM, shihanzhang wrote: hi Miguel Angel

Re: [openstack-dev] Multiple API/RPC process behavior

I'd recommend you to go for ml2, as openvswitch alone plugin will be removed during Juno, making an upgrade path harder on your side. I suppose there could be a bug/noimplementation for multiplerpc workers within openvswitch plugin, but as it's deprecated there are high chances that it won't be f

Re: [openstack-dev] [neutron]Performance of security group

--- Hash: SHA512 On 02/07/14 10:12, Miguel Angel Ajo wrote: Shihazhang, I really believe we need the RPC refactor done for this cycle, and given the close deadlines we have (July 10 for spec submission and July 20 for spec approval). Don't you think it's going to be better to split the

Re: [openstack-dev] [neutron]Performance of security group

I have created a separate spec for the RPC part. https://review.openstack.org/104522 On 07/02/2014 05:52 PM, Kyle Mestery wrote: On Wed, Jul 2, 2014 at 3:43 AM, Ihar Hrachyshka wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/07/14 10:12, Miguel Angel Ajo wrote: Shihazhang

Re: [openstack-dev] [stable][neutron] How we handle Kilo backports

+1 for Critical + High. Kevin Benton wrote: +1. Anything that lands in the high category is usually something that will have a big operational impact. On Wed, Nov 18, 2015 at 8:44 AM, Ihar Hrachyshka wrote: Hi all, as per [1] I imply that all projects under stable-maint-core team supervision

[openstack-dev] [neutron] [QoS] meeting rebooted

Hi everybody, We're restarting the QoS meeting for next week, Here are the details, and a preliminary agenda, https://etherpad.openstack.org/p/qos-mitaka Let's keep QoS moving!, Best, Miguel Ángel. _

Re: [openstack-dev] [neutron] [QoS] meeting rebooted

[mailto:ihrac...@redhat.com] Sent: Friday, November 20, 2015 12:08 PM To: Miguel Angel Ajo Cc: OpenStack Development Mailing List (not for usage questions); victor.r.how...@gmail.com; irenab@gmail.com; Moshe Levi; Vikram Choudhary; Gal Sagie; Haim Daniel Subject: Re: [neutron] [QoS] meeting rebooted

Re: [openstack-dev] [all] Time to increase our IRC Meetings infrastructure?

+1, It's always very confusing the first time. Thierry Carrez wrote: Tony Breeds wrote: [...] Confusion = So this is really quite trivial. As you can see above we don't have an #openstack-meeting-2 channel the ...-alt is clearly that, but still people are confused. How would peop

Re: [openstack-dev] [Neutron] Call for review focus

Assaf Muller wrote: On Mon, Nov 23, 2015 at 7:02 AM, Rossella Sblendido wrote: On 11/20/2015 03:54 AM, Armando M. wrote: On 19 November 2015 at 18:26, Assaf Mullermailto:amul...@redhat.com>> wrote: On Wed, Nov 18, 2015 at 9:14 PM, Armando M.mailto:arma...@gmail.com>> wrote: >

Re: [openstack-dev] [Neutron] Bug deputy process

I can only agree with the opinions others already expressed. It’s been a very good initiative. Going through the bugs everyday during my week opened my eyes to how the end users face bugs, an the kind of issues we have. I got myself educated into following the incoming bug stream from launchpad

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

I agree with Gary here, The 21:00 UTC time here is a difficult time for me, because it's exactly the time of getting kids to sleep at home. It's generally very unpredictable for me. I missed last meeting exactly because of that, laptop was ready, I was ready, kids didn't cooperate.

[openstack-dev] [neutron] [QoS] Phantom meeting

Hi everybody, We held a short meeting today because the calendar was saying today we had another biweekly meeting, regardless of having another one last week. So I guess next week we have no meeting unless we want to have another short one too. Minutes are here: http://eavesdrop

[openstack-dev] [neutron][qos] Priorities & Status for QoS

I've been working on assembling a QoS[1] POC since last day of the coding sprint in Israel [2], Ihar has reported to the list our plan to get into master [3]. I've been able to validate and integrate lots of the patches, and find the gaps, while still finishing the top-down assembly may requi

Re: [openstack-dev] [neutron][qos] Priorities & Status for QoS

Miguel Angel Ajo wrote: I've been working on assembling a QoS[1] POC since last day of the coding sprint in Israel [2], Ihar has reported to the list our plan to get into master [3]. I've been able to validate and integrate lots of the patches, and find the gaps, while still fin

Re: [openstack-dev] [neutron] - Proposing Miguel Angel Ajo for the Control Plane core team

ote: Hello! As the Lieutenant of the built-in control plane[1], I am proposing to add Miguel Angel Ajo to the control plane core reviewer team. His review stats are inline with the other core reviewers[2], and his work on improving the stability/performance of the agents over the last year h

Re: [openstack-dev] [neutron] Adding results to extension callbacks (ml2 port_update ext handling).

Inline reply (I've added to CC relevant people for ml2/plugin.py port_update extension handing -via git blame-) as they probably have an opinion here (specially the last two options). Kevin Benton wrote: This sounds like a lot of overlap with the dict extend functions. Why weren't they adequat

Re: [openstack-dev] [neutron][qos] request to merge feature/qos back into master

I owe you all a video of the feature to show how does it work. I was supposed to deliver today, but I've been partly sick during today, The script is ready, I just have to record and share, hopefully happening tomorrow (Friday). Best, Miguel Ángel Ihar Hrachyshka wrote: -BEGIN PGP SIGNED M

Re: [openstack-dev] [neutron][qos] request to merge feature/qos back into master

and here's the video: http://www.ajo.es/post/126667247769/neutron-qos-service-plugin Cheers, Miguel Ángel. Miguel Angel Ajo wrote: I owe you all a video of the feature to show how does it work. I was supposed to deliver today, but I've been partly sick during today, The script i

Re: [openstack-dev] [Neutron] revert default review branch to master

Thanks for handling this so quickly Sean! Kyle Mestery wrote: On Mon, Aug 17, 2015 at 5:58 PM, Jeremy Stanley wrote: On 2015-08-17 22:39:56 + (+), Mooney, Sean K wrote: [...] Assuming this was not intentional I have opened a bug and submitted a patch to revert this change. [...] Fi

Re: [openstack-dev] [neutron][api] - attaching arbitrary key/value pairs to resources

Doug Wiegley wrote: In general, the fight in Neutron *has* to be about common definitions of networking primitives that can be potentially implemented by multiple backends whenever possible. That's the entire point of Neutron. I get that it's hard, but that's the value Neutron brings to th

Re: [openstack-dev] [neutron][db] reviewers: please mind the branch a script belongs to

Good reminder, I believe automation will help us most of the time. But we need to have a good eye on contract/expand branches, Ihar Hrachyshka wrote: Hi reviewers, several days ago, a semantically expand-only migration script was merged into contract branch [1]. This is not a disaster, though

[openstack-dev] [neutron][nova] QoS Neutron-Nova integration

Hi, Looking forward to the M cycle, I was wondering if we could loop you in our next week Neutron/QoS meeting on #openstack-meeting-3 around 16:00 CEST Sept 16th. We're thinking about several ways we should integrate QoS between nova and the new extendable QoS service on n

Re: [openstack-dev] [all] gerri performance

I am experiencing it, yes :/ Gary Kotton wrote: Hi, Anyone else experiencing bad performance with gerri at the moment? Access files in a review takes ages. So now the review cycle will be months instead of week Thanks Gary _

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

I didn't finish reading it, and was thinking about the same thing exactly. IMHO option 4th is the best. So we will be able to provide an interface where stability is controlled, where we can deprecate things in a controlled manner, and we know what we support and what we don't. Do you have a

Re: [openstack-dev] [all] -1 due to line length violation in commit messages

IMO those checks should be automated, as we automate pep8 checks on our python code. I agree, that if we have a rule for this, we should follow it, but it's a waste of time reviewing and enforcing this manually. Best regards. Miguel Ángel. Gorka Eguileor wrote: On 26/09, Morgan Fainberg wrot

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

Ihar Hrachyshka wrote: On 30 Sep 2015, at 12:08, thomas.mo...@orange.com wrote: Hi Ihar, Ihar Hrachyshka : Miguel Angel Ajo : Do you have a rough idea of what operations you may need to do? Right now, what bagpipe driver for networking-bgpvpn needs to interact with is: - int_br OVSBridge

Re: [openstack-dev] [Sender Auth Failure] Re: [neutron] New cycle started. What are you up to, folks?

Johnston, Nate wrote: I was wondering if you provide a little bit more background on the QoS item, "-- remove RPC upgrade tech debt that we left in L (that should open path for new QoS rules that are currently blocked by it);”. Is this related to the issue you point out in the commit messag

Re: [openstack-dev] [neutron][ovn] New cycle started. What are you up to, folks?

Very nice thread. Sharing is caring, so... (please notice some of my ideas are aligned with Ihar): * Kill bugs * Kill bugs * Kill bugs * RPC Neutron Objects Callback: - upgrade path: That wasn't needed before, but we're going to need it. - implement an strategy to avoid the out-of-order

Re: [openstack-dev] [neutron] New cycle started. What are you up to, folks?

Moshe Levi wrote: -Original Message- From: Sean M. Collins [mailto:s...@coreitpro.com] Sent: Thursday, October 01, 2015 6:42 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] New cycle started. What are you up to, folks? On Thu,

Re: [openstack-dev] [Neutron] Defect management

Hi, I was trying to help a bit, for now, but I don't have access in launchpad to update importance, etc. I will add comments on the bugs themselves, and set a ? in the spreadsheet. Cheers, and thanks Armando for leading this, it's a good change. I will be happy to take the bug deputy positi

Re: [openstack-dev] [neutron] Neutron rolling upgrade - are we there yet?

Rossella Sblendido wrote: Hello Artur, thanks for staring this thread. See inline please. On 10/15/2015 05:23 PM, Ihar Hrachyshka wrote: Hi Artur, thanks a lot for caring about upgrades! There are a lot of good points below. As you noted, surprisingly, we seem to have rolling upgrades worki

Re: [openstack-dev] [neutron][stable] proactive backporting

I thought that may be, some of the work Ihar is proposing, could be automated. Like, for example, checking if bug fixes are backportable as-is to the previous stable branches, and if they pass testing. If that's the case, the bot could automatically automatically add the bug to the list, or

[openstack-dev] [neutron] Regarding Flow classifiers existing proposals

Added openstack-dev, where I believe this conversation must live. I totally agree on this, thank you for bringing up this conversation. This is not something we want to do for QoS this cycle, but probably next cycle. Anyway, an unified data model and API to create/update classifiers will not

Re: [openstack-dev] [neutron] Regarding Flow classifiers existing proposals

Gal, if you have some time to coordinate this with the service chaining/firewall folks and start a spec, it’d be amazing. Best regards, Miguel Angel Ajo On Friday 5 June 2015 at 12:42, Vikram Choudhary wrote: > Hi Gal, > > It's really nice that you are also interested. Mys

Re: [openstack-dev] [all] cross project communication: Return request-id to caller

On Wednesday 3 June 2015 at 12:13, Miguel Ángel Ajo wrote: > Doesn’t this overlap with the work done for the OSProfiler ? > > > More comments inline. > > Miguel Ángel Ajo > > > On Wednesday, 3 de June de 2015 at 11:43, Kekane, Abhishek wrote: > > > Hi Devs, > > > > So for I hav

Re: [openstack-dev] [neutron] Regarding Flow classifiers existing roposals

the next IRC meeting agenda. > > Thanks, > Cathy > > From: Henry Fourie > Sent: Friday, June 05, 2015 11:27 AM > To: Miguel Angel Ajo; Vikram Choudhary > Cc: azama-y...@mxe.nes.nec.co.jp (mailto:azama-y...@mxe.nes.nec.co.jp); Cathy > Zhang; arma...@gmail.com (mailt

Re: [openstack-dev] [Neutron] API Extensions - Namespace URLs

Thanks for asking about this Sean! ;) Sean M. Collins wrote: On Tue, Jun 09, 2015 at 05:21:18PM EDT, Kevin Benton wrote: I wasn't planning on wiping them out for now since I'm leveraging a lot of the extension loading that exists so someone can remove the namespaces if they want. OK -

Re: [openstack-dev] Proposing Brian Haley to Neutron L3 Core Reviewer Team

Here too, my vote doesn’t count, but big+1, all my interactions with Brian have been awesome, and he’s been doing a very good job for a long time. Best, Miguel Ángel Ajo On Thursday 11 June 2015 at 12:27, Gary Kotton wrote: > +1 > > On 6/10/15, 10:11 PM, "Carl Baldwin" (mailto:c...@ecbaldwin

Re: [openstack-dev] [Neutron] Proposing YAMAMOTO Takashi for the Control Plane core team

I know my vote does not count, but “big +1” from me :) Best, Miguel Ángel Ajo On Thursday 11 June 2015 at 22:24, Armando M. wrote: > +1 > > On 11 June 2015 at 12:42, Carl Baldwin (mailto:c...@ecbaldwin.net)> wrote: > > +1 > > > > On Thu, Jun 11, 2015 at 12:15 PM, Kevin Benton > (mailto:bl

[openstack-dev] [neutron] slimming down (the RFE) process for small internal design stuff

A few days ago, I was talking to Rossella, about the need of a RFE for this [1], in this case, it's an internal library/nicety for neutron development. It's not a feature from the user point of view. And it's not a very big change. So, we thought that starting by a simple devref to agree on, an

Re: [openstack-dev] [Neutron][Ironic] Setting IPXE tag for dnsmasq

What does iPXE do exactly?, What are the implications of having this enabled by default? Cheers, Miguel Ángel Kevin Benton wrote: I'd like to resurrect this thread. The patch has been sitting for quite a while. Since it doesn't modify the responses by default of DHCP messages, I'm inclined t

Re: [openstack-dev] [Neutron] [QOS] Request for Additional QoS capabilities

Hi John, I guess it totally makes sense as a new type of rule for QoS, once the framework is ready, it could make sense to add a "connection per second limit" or "max connection limit" type of rule. John Joyce (joycej) wrote: Gal: I had seen the brute force blueprint and noticed how close the

Re: [openstack-dev] [Neutron][Ironic] Setting IPXE tag for dnsmasq

So just enabling it won't have any effect. http://www.richud.com/wiki/Network_iPXE_dnsmasq_Examples_PXE_BOOT On Fri, Jun 19, 2015 at 9:21 AM, Miguel Angel Ajo __ OpenStack Development Mailing List (not for usa

Re: [openstack-dev] [Neutron][Ironic] Setting IPXE tag for dnsmasq

So just enabling it won't have any effect. http://www.richud.com/wiki/Network_iPXE_dnsmasq_Examples_PXE_BOOT On Fri, Jun 19, 2015 at 9:21 AM, Miguel Angel Ajo __ OpenStack Development Mailing List (not for usa

Re: [openstack-dev] [Neutron] Modular L2 Agent

In the context of Quality of Service, we need to extend the L2 agents (SR-IOV, OVS and LB), and we didn't want to simply hijack the processing loop of the agents, but take a moment, and put together a Modular L2 design https://review.openstack.org/#/c/189723/ If you find it reasonable to do

Re: [openstack-dev] [Neutron] Proposing Rossella Sblendido for the Control Plane core team

I missed this one!, congratulations Rosella :-) Anna Kamyshnikova 20 Jun 2015 11:55via Postbox Congratulations Rossella!

Re: [openstack-dev] [neutron] Regarding Flow classifiers existing proposals

om: Vikram Choudhary Sent: 05 June 2015 14:42 To: 'Miguel Angel Ajo' Cc: azama-y...@mxe.nes.nec.co.jp; Henry Fourie; Cathy Zhang; arma...@gmail.com; Dongfeng (C); Kyle Mestery; openstack-dev@lists.openstack.org; Dhruv Dhody; Kalyankumar Asangi Subject: RE: [neutron] Regarding Flow classifier

[openstack-dev] [neutron][oslo][all] publisher/subscriber mechanism for resources (fanout+versioned objects)

Hi all, Within the neutron/QoS design I've been working on the messaging bits trying to design an architecture [1][2] which allowed (in combination with oslo versioned objects) easy distribution of resource changes across interested subscribers. Our use case is neutron-server (or servi

[openstack-dev] [neutron] QoS code sprint

Hi everybody, Next week, from Tue (Jul 29th) to Thu (Jun 2nd), a few of us will be physically [1] attending the neutron QoS coding sprint in Ra'anana (Israel) @ the Red Hat office. And a few others have expressed their will to join us remotely (Thanks!!) :) I guess a reasonabl

Re: [openstack-dev] [neutron] QoS code sprint

forward to contribute in the best way we can 😀 On 26-Jun-2015 3:33 pm, "Miguel Angel Ajo" wrote: Hi everybody, Next week, from Tue (Jul 29th) to Thu (Jun 2nd), a few of us will be physically [1] attending the neutron QoS coding sprint in Ra'anana (Israel) @ the Red Hat office.

Re: [openstack-dev] [neutron] Rotating the weekly Neutron meeting

+1 - Original Message - > like it! +1 > > Fawad Khaliq > > > On Wed, Aug 13, 2014 at 7:58 AM, mar...@redhat.com < mandr...@redhat.com > > wrote: > > > > On 13/08/14 17:05, Kyle Mestery wrote: > > Per this week's Neutron meeting [1], it was decided that offering a > > rotating meeting

[openstack-dev] [neutron] Ipnetns+rootwrap, two different issues

Hi Eugene, I'd like to ask you to reconsider the -1 on this review: a) https://review.openstack.org/#/c/114928/ I'm tackling a different issue than Kevin here: b) https://review.openstack.org/#/c/109736/ I'm trying to allow general use of the IpNetns wrapper when namespace=N

Re: [openstack-dev] [neutron]Performance of security group

gt;-BEGIN PGP SIGNED MESSAGE- > >>Hash: SHA512 > >> > >>Oh, so you have the enhancement implemented? Great! Any numbers that > >>shows how much we gain from that? > >> > >>/Ihar > >> > >>On 03/07/14 02:49, shihanzhan

Re: [openstack-dev] [neutron]Performance of security group

had time yet. > I'll try to remedy that by the weekend. > > Thanks! > Kyle > > > Best regards, > > shihanzhang > > > > > > > > > > > > At 2014-07-03 10:08:21, "Ihar Hrachyshka" < ihrac...@redhat.com > wrote: > >&

Re: [openstack-dev] [neutron] Runtime checks vs Sanity checks

In spite of my +1 I actually agree. I had forgotten about the sanity check framework. We put it in place to avoid an excessive (and growing) amount of checks to be done in runtime. In this case several agents need would be doing the same check. We should do things either one way or another, but

Re: [openstack-dev] [neutron] Juno-3 BP meeting

Works perfect for me. I will join. Sent from my Android phone using TouchDown (www.nitrodesk.com) -Original Message- From: Carl Baldwin [c...@ecbaldwin.net] Received: Wednesday, 27 Aug 2014, 5:07 To: OpenStack Development Mailing List [openstack-dev@lists.openstack.org] Subject: Re: [

Re: [openstack-dev] [neutron] Juno-3 BP meeting

If we yet had time at the end, as a lower priority, I'd like to talk about: https://blueprints.launchpad.net/neutron/+spec/agent-child-processes-status Which I believe is in good shape (l3 & dhcp are implemented, and leave the bases to do the work for all other agents). - Original Mess

Re: [openstack-dev] [neutron] Status of Neutron at Juno-3

I didn't know that we could ask for FFE, so I'd like to ask (if yet in time) for: https://blueprints.launchpad.net/neutron/+spec/agent-child-processes-status https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/agent-child-processes-status,n,z To get th

Re: [openstack-dev] [nova][neutron] default allow security group

I believe your request matches this, and I agree it'd be something good https://blueprints.launchpad.net/neutron/+spec/default-rules-for-default-security-group And also, the fact that we have hardcoded default security group settings. It would be good to have a system wide default security gro

Re: [openstack-dev] [neutron] [nova] non-deterministic gate failures due to unclosed eventlet Timeouts

Good catch John, and good work Angus! ;) This will save a lot of headaches. - Original Message - > On Mon, 8 Sep 2014 05:25:22 PM Jay Pipes wrote: > > On 09/07/2014 10:43 AM, Matt Riedemann wrote: > > > On 9/7/2014 8:39 AM, John Schwarz wrote: > > >> Hi, > > >> > > >> Long story short: f

[openstack-dev] [neutron] Ipset, merge refactor for J?

During the ipset implementatio, we designed a refactor [1] to cleanup the firewall driver a bit, and move all the ipset low-level knowledge down into the IpsetManager. I'd like to see this merged for J, and, it's a bit of an urgent matter to decide, because we keep adding small changes [2] [3

Re: [openstack-dev] [neutron] Ipset, merge refactor for J?

On 09/16/2014 03:57 AM, Thierry Carrez wrote: > >> Miguel Angel Ajo Pelayo wrote: > >>> During the ipset implementatio, we designed a refactor [1] to cleanup > >>> the firewall driver a bit, and move all the ipset low-level knowledge > >>> down into the

Re: [openstack-dev] [Neutron][qa] Parallel testing update

Hi Salvatore!, Good work on this. About the quota limit tests, I believe they may be unit-tested, instead of functionally tested. When running those tests in parallel with any other tests that rely on having ports, networks or subnets available into quota, they have high chances of ma

Re: [openstack-dev] [nova][neutron]About creating vms without ip address

Hi Dong, Can you elaborate an example of what you get, and what you were expecting exactly?. I have a similar problem within one operator, where they assign you sparse blocks of IP addresses (floating IPs), directly routed to your machine, and they also assign the virtual mac add

[openstack-dev] [neutron][ha][agents] host= parameter

Hi!, I want to ask, specifically, about the intended purpose of the host=... parameter in the neutron-agents (undocumented AFAIK). I haven't found any documentation about it. As far as I discovered, it's being used to provide Active/Passive replication of agents, as you can manage agent

Re: [openstack-dev] [neutron][ha][agents] host= parameter

Hi, any feedback on this? If there is not, and it does seem right, I will go on adding the documentation of this parameter to the agent config files. Best Regards, Miguel Ángel. - Original Message - > From: "Miguel Angel Ajo Pelayo" > To: "OpenStack Development

Re: [openstack-dev] [Neutron] backporting database migrations to stable/havana

Hi Ralf, I see we're on the same boat for this. It seems that a database migration introduces complications for future upgrades. It's not an easy path. My aim when I started this backport was trying to scale out neutron-server, starting several ones together. But I'm afraid we would find

Re: [openstack-dev] [Neutron] backporting database migrations to stable/havana

- Original Message - > From: "Miguel Angel Ajo Pelayo" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Tuesday, February 4, 2014 6:36:16 PM > Subject: Re: [openstack-dev] [Neutron] backporting database migrati

Re: [openstack-dev] [Neutron] backporting database migrations to stable/havana

t; On Tue, Feb 04, 2014 at 12:36:16PM -0500, Miguel Angel Ajo Pelayo wrote: > > > > > > Hi Ralf, I see we're on the same boat for this. > > > >It seems that a database migration introduces complications > > for future upgrades. It's not an

[openstack-dev] [neutron] [HA] blueprint: Provide agent service status which can be queried via init.d script or parent process

During the design of HA deployments for Neutron, I have found that agent's could run into problems, and they keep running, but they have no methods to expose status to parent process or which could be queried via an init.d script. So I'm proposing this blueprint, https://blueprints.launchpad.n

[openstack-dev] [neutron] [stable/havana] cherry backport, multiple external networks, passing tests

Could any core developer check/approve this if it does look good? https://review.openstack.org/#/c/68601/ I'd like to get it in for the new stable/havana release if it's possible. Best regards, Miguel Ángel ___ OpenStack-dev mailing list OpenS

Re: [openstack-dev] [neutron] [stable/havana] cherry backport, multiple external networks, passing tests

ons)" > > Cc: "openstack-stable-maint" > Sent: Wednesday, February 12, 2014 12:05:29 PM > Subject: Re: [openstack-dev] [neutron] [stable/havana] cherry backport, > multiple external networks, passing tests > > 2014-02-12 10:48 GMT+01:00 Miguel Angel Ajo Pelayo : &

Re: [openstack-dev] [Openstack-stable-maint] Stable gate status?

I rebased the https://review.openstack.org/#/c/72576/ no-op change. - Original Message - > From: "Alan Pevec" > To: "openstack-stable-maint" > Cc: "OpenStack Development Mailing List" > Sent: Tuesday, February 18, 2014 7:52:23 PM > Subject: Re: [openstack-dev] [Openstack-stable-maint

Re: [openstack-dev] [neutron] when icehouse will be frozen

If I didn't understand it wrong, as long as you have an active review for your change, and some level of interest / approval, then you should be ok to finish it during the last Icehouse cycle, but of course, your code needs to be approved to become part of Icehouse. Cheers, Miguel Ángel. - O

Re: [openstack-dev] [Neutron] Should we clean resource first then do assert in test?

Correct, So, it's better to keep tests clean of de resource cleanups for readability purposes and easier maintenance. Sent from my Android phone using TouchDown (www.nitrodesk.com) -Original Message- From: Kevin Benton [blak...@gmail.com] Received: Wednesday, 19 Nov 2014, 5:18 To:

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

- Original Message - > Miguel Angel Ajo wrote: > > [...] > >The overhead comes from python startup time + rootwrap loading. > > > >I suppose that rootwrap was designed for lower amount of system calls > > (nova?). > > Yes, it was no

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

I'd > like to come up with some actions this week to try to address at least > part of the problem before Icehouse releases. > > https://etherpad.openstack.org/p/neutron-agent-exec-performance > > Carl > > On Mon, Mar 10, 2014 at 5:26 AM, Miguel Angel Ajo > wr

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

tmp/pypy-2.2.1-src$ time ./tmp-c > hello world > > real 0m0.021s > user 0m0.000s > sys 0m0.020s > jogo@dev:~/tmp/pypy-2.2.1-src$ time python -S ./tmp.py > hello world > > real 0m0.010s > user 0m0.000s > sys 0m0.008s > > jogo@dev:~/tmp/pypy-2.2.1-src$ t

Re: [openstack-dev] [Neutron] Killing connection after security group rule deletion

Hi! This is an interesting topic, I don't know if there's any way to target connection tracker rules by MAC, but that'd be the ideal solution. I also understand the RETURN for RELATED,ESTABLISHED is there for performance reasons, and removing it would lead to longer table evaluation, and deg

[openstack-dev] [neutron] [stable] Tool to aid in scalability problems mitigation.

Recently, we have identified clients with problems due to the bad scalability of security groups in Havana and Icehouse, that was addressed during juno here [1] [2] This situation is identified by blinking agents (going UP/DOWN), high AMQP load, nigh neutron-server load, and timeout fr

  1   2   3   >