Re: [openstack-dev] [Neutron] Being more aggressive with our defaults

> On 09 Feb 2016, at 21:43, Sean M. Collins wrote: > > Kevin Benton wrote: >> I agree with the mtu setting because there isn't much of a downside to >> enabling it. However, the others do have reasons to be disabled. >> >> csum - requires runtime detection of support for a feature and then auto

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

Thinking of this, I had another idea, a bit raw yet. But how does it sound to have two meetings a week, one in a EU/ASIA friendlier timezone, and another for USA/AU (current one), with different chairs. We don't impose unnatural-working hours (too early, too late for family, etc..) to anyone, we

Re: [openstack-dev] [neutron][QoS] service-plugin or not discussion

> On 24/4/2015, at 19:42, Armando M. wrote: > > > > On 24 April 2015 at 01:47, Miguel Angel Ajo Pelayo <mailto:mangel...@redhat.com>> wrote: > Hi Armando & Salvatore, > >> On 23/4/2015, at 9:30, Salvatore Orlando > <mailto:sorla...@nicira.com&

Re: [openstack-dev] [neutron][QoS] service-plugin or not discussion

Hi Armando & Salvatore, > On 23/4/2015, at 9:30, Salvatore Orlando wrote: > > > > On 23 April 2015 at 01:30, Armando M. <mailto:arma...@gmail.com>> wrote: > > On 22 April 2015 at 06:02, Miguel Angel Ajo Pelayo <mailto:mangel...@redhat.com>> wrot

[openstack-dev] [neutron][QoS] service-plugin or not discussion

Hi everybody, In the latest QoS meeting, one of the topics was a discussion about how to implement QoS [1] either as in core, or as a service plugin, in, or out-tree. It’s my feeling, and Mathieu’s that it looks more like a core feature, as we’re talking of port properties that we define

Re: [openstack-dev] [Openstack-operators] [Neutron] The specs process, effective operators feedback and product management

The rally process (email based) doesn’t seem scalable enough for the neutron case IMHO, but I agree that a voting system doesn’t differ too much from launchpad and that it can be gamed. > On 22/4/2015, at 1:21, Assaf Muller wrote: > > Just to offer some closure, it seems like the voting idea wa

Re: [openstack-dev] [neutron] [QoS] weekly meeting - update

> On 20/4/2015, at 16:03, Kyle Mestery wrote: > > On Mon, Apr 20, 2015 at 8:44 AM, Ihar Hrachyshka <mailto:ihrac...@redhat.com>> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 04/20/2015 12:20 PM, Miguel Angel Ajo Pelayo wrote: > > Tha

Re: [openstack-dev] [neutron] [QoS] weekly meeting - update

Thank you Irena, I believe this last minute change deserves an explanation, I asked Irena to write to the list on my behalf (thank you!). I got a surgery to one of my kids scheduled on Wednesday (it’s something very mild near the ear), also it’s holiday for a few of the participants that w

Re: [openstack-dev] [all] Introducing the Cloud Service Federation project (cross-project design summit proposal)

Sounds like a very interesting idea. Have you talked to the keystone folks?, I would do this work into the keystone project itself (just a separate daemon). This still looks like identity management (federated, but identity) I know the burden of working with a mainstream project could be higher

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

an existing one… ‘:D ) minutes of this preliminary meeting can be found here: http://eavesdrop.openstack.org/meetings/neutron_qos/2015/neutron_qos.2015-04-15-14.07.html Best, Miguel Ángel > On 15/4/2015, at 16:32, Veiga, Anthony > wrote: > > On Apr 15, 2015, at 10:00 , Migu

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

en the two of them if absolutely > necessary (it’s IRC, after all) but would prefer they not overlap if > possible. Thanks! > -Anthony > >> On Apr 15, 2015, at 6:39 , Miguel Angel Ajo Pelayo > <mailto:mangel...@redhat.com>> wrote: >> >> I saw Mathieu Ro

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

uel Ángel > On 14/4/2015, at 10:43, Miguel Angel Ajo Pelayo wrote: > > Ok, after one week, looks like the most popular time slot is B, > that is 14:00 UTC / Wednesdays. > > I’m proposing first meeting for Wednesday / Apr 22th 14:00 UTC / > #openstack-meeting-2. > >

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

> On 10/4/2015, at 20:10, Kyle Mestery wrote: > > On Fri, Apr 10, 2015 at 1:03 PM, Sean M. Collins > wrote: > We already tried to make Neutron the default with OVS - and the results > were not good[1]. > > Operators who are currently not using Neutron have said that

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

Ok, after one week, looks like the most popular time slot is B, that is 14:00 UTC / Wednesdays. I’m proposing first meeting for Wednesday / Apr 22th 14:00 UTC / #openstack-meeting-2. Tomorrow (Apr 15th / 14:00 UTC) It’s a been early since the announcement, so I will join #openstack-meeting-2 wh

Re: [openstack-dev] [all][pbr] splitting our deployment vs install dependencies

> On 13/4/2015, at 3:53, Robert Collins wrote: > > On 13 April 2015 at 13:09, Robert Collins wrote: >> On 13 April 2015 at 12:53, Monty Taylor wrote: >> >>> What we have in the gate is the thing that produces the artifacts that >>> someone installing using the pip tool would get. Shipping any

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

Hi Anthony, nice to hear about it! :) Is the implementation available somewhere?, IMHO, the design should be what’s best for the whole neutron project looking into future extension of the design, by this I mean that we should not influence the design by what was already designed D/S, *but*,

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

Hi Raghunath, feel free to look at: https://wiki.openstack.org/wiki/Meetings and suggest other timeslots with a free meeting room, this is a very wide community, and it’s impossible to get a timeslot in everybody working hours. Please note that option

Re: [openstack-dev] [all][oslo][clients] Let's speed up start of OpenStack libs and clients by optimizing imports with profimp

> On 7/4/2015, at 0:43, Robert Collins wrote: > > On 7 April 2015 at 05:11, Joe Gordon wrote: >> >> >> On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews >> wrote: >>> >>> >>> On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic wrote: Jay, > Not far, IMHO. 100ms differen

Re: [openstack-dev] [neutron] OpenFlow security groups (pre-benchmarking plan)

Sharing thoughts that I was having: May be during the next summit it’s worth discussing the future of the reference agent(s), I feel we’ll be replicating a lot of work across OVN/OVS/RYU(ofagent) and may be other plugins, I guess until OVN and it’s integration are ready we can’t stop, so it ma

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][Spec freeze exception] Rootwrap daemon ode support

cate some time and do it > right away. > > [1] https://review.openstack.org/#/c/93889/ > -- > Miguel Ángel Ajo > Sent with Sparrow <http://www.sparrowmailapp.com/?sig> > > On Thursday, 24 de July de 2014 at 01:42, Miguel Angel Ajo Pelayo wrote: > > +1 > > Sent fro

Re: [openstack-dev] [neutron] Lightning talks during the Design Summit!

Thank you very much, voted. - Original Message - > On Thu, Oct 23, 2014 at 3:22 PM, Kyle Mestery wrote: > > As discussed during the neutron-drivers meeting this week [1], we've > > going to use one of the Neutron 40 minute design summit slots for > > lightning talks. The basic idea is we

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

Thanks for your feedback too Ihar, comments inline. - Original Message - > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 24/10/14 11:56, Miguel Angel Ajo Pelayo wrote: > > > > > > - Original Message - > >> Hi Miguel, > >&g

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

sorry: when I said boot, I mean "openvswitch agent restart". - Original Message - > > Kevin, I agree, with you, 1 zone per port should be reasonable. > > The 2^16 rule limit will force us into keeping state (to tie > ports to zones across reboots), may be this state can be just > recover

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

Kevin, I agree, with you, 1 zone per port should be reasonable. The 2^16 rule limit will force us into keeping state (to tie ports to zones across reboots), may be this state can be just recovered by reading the iptables rules at boot, and reconstructing the current openvswitch-agent local port/z

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

my point here is that direct upstream review time would result in better quality code here, and could certainly spot any hidden bugs, and increase testing quality. It also reduces packaging time all across distributions making it available via the standard neutron repository. Thanks for the fee

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

Nice!, It sounds like a good mechanism to handle this. Defining a good mechanism here is crucial, we must be aware of the 2^16 zones limit [1], and that ipset rules will coalesce connections to lots of different IPs over the same rule. May be a good option is to tag connections per rule (we li

[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

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

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

[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] [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

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] 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] [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] 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] 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]Performance of security group

; >>>> Juno cycle. If we go for something too complicated is going to > >>>> take more time for approval. > >>> > >>> > >>> I agree. And it not only increases chances to get at least some of > >>> those highly demanded performa

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

t;>>> take more time for approval. > >>> > >>> > >>> I agree. And it not only increases chances to get at least some of > >>> those highly demanded performance enhancements to get into Juno, > >>> it's also "the right

[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] 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

Re: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon mode support

+1 Sent from my Android phone using TouchDown (www.nitrodesk.com) -Original Message- From: Yuriy Taraday [yorik@gmail.com] Received: Thursday, 24 Jul 2014, 0:42 To: OpenStack Development Mailing List [openstack-dev@lists.openstack.org] Subject: [openstack-dev] [Neutron][Spec freeze e

Re: [openstack-dev] [neutron] Spec Proposal Deadline has passed, a note on Spec Approval Deadline

The oslo-rootwrap spec counterpart of this spec has been approved: https://review.openstack.org/#/c/94613/ Cheers :-) - Original Message - > Yurly, thanks for your spec and code! I'll sync with Carl tomorrow on this > and see how we can proceed for Juno around this. > > > On Sat, Jul 1

Re: [openstack-dev] [neutron] Spec Proposal Deadline has passed, a note on Spec Approval Deadline

+1 Sent from my Android phone using TouchDown (www.nitrodesk.com) -Original Message- From: Carl Baldwin [c...@ecbaldwin.net] Received: Saturday, 12 Jul 2014, 17:04 To: OpenStack Development Mailing List [openstack-dev@lists.openstack.org] Subject: Re: [openstack-dev] [neutron] Spec Prop

Re: [openstack-dev] [neutron][all] switch from mysqldb to another eventlet aware mysql client

+1 here too, Amazed with the performance gains, x2.4 seems a lot, and we'd get rid of deadlocks. - Original Message - > +1 > > I'm pretty excited about the possibilities here. I've had this > mysqldb/eventlet contention in the back of my mind for some time now. > I'm glad to see some

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

>> > >> Let's leave one spec per enhancement. @Shihazhang, what do you > >> think? > >> > >> > >>> Also, I proposed the details of "2", trying to bring awareness > >>> on the topic, as I have been working with the sc

[openstack-dev] [neutron] respawn/action neutron-*-agent dying childs.

Eugene (& list) I just saw that you reassigned the bug to yourself recently , and that the ideas described in the bug differ a bit from the idea that I had, but I'd be willing to extend my spec to incorporate your design and spend some time in the problem if you believe it's feasible. I'm

Re: [openstack-dev] [Neutron] - Location for common third-party libs?

+1 Anyway, we would need to have caution on how the new single-package would provide the old ones to handle the upgrade from split to single, and also, back compatibility with the deployment tools. Anyway, wouldn't it be openstack-neutron instead of python-neutron ? - Original Message -

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

I'd like to bring the attention back to this topic: Mark, could you reconsider removing the -2 here? https://review.openstack.org/#/c/93889/ Your reason was: """Until the upstream blueprint (https://blueprints.launchpad.net/oslo/+spec/rootwrap-daemon-mode ) merges in Oslo it does not

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

com > > > wrote: > > > > > > > > hi Miguel Ángel, > > I am very agree with you about the following point: > > > * physical implementation on the hosts (ipsets, nftables, ... ) > > --this can reduce the load of compute node. > > > *

Re: [openstack-dev] [Neutron] DVR demo and how-to

Thank you for the video, keep up the good work!, - Original Message - > Hi folks, > > The DVR team is working really hard to complete this important task for Juno > and Neutron. > > In order to help see this feature in action, a video has been made available > and link can be found in [

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

ce the load of compute node. > > * rpc communication mechanisms. > -- this can reduce the load of neutron server > can you help me to review my BP specs? > > > > > > > > At 2014-06-19 10:11:34, "Miguel Angel Ajo Pelayo" < mangel...@redhat.com &

Re: [openstack-dev] [Neutron]One security issue about floating ip

Yes, once a connection has past the nat tables, and it's on the kernel connection tracker, it will keep working even if you remove the nat rule. Doing that would require manipulating the kernel connection tracking to kill that connection, I'm not familiar with that part of the linux network stac

Re: [openstack-dev] [Neutron] default security group rules in neutron

I believe it's an important feature, because currently the default security rules are hard-coded in neutron's code, and that won't fit all organizations (not to say that the default security rules won't scale well on our current implementation). Best, Miguel Ángel - Mensaje origin

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

Hi it's a very interesting topic, I was getting ready to raise the same concerns about our security groups implementation, shihanzhang thank you for starting this topic. Not only at low level where (with our default security group rules -allow all incoming from 'default' sg- the iptable rules

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][rootwrap] Performance considerations, sudo?

Hi Carl, thank you, good idea. I started reviewing it, but I will do it more carefully tomorrow morning. - Original Message - > All, > > I was writing down a summary of all of this and decided to just do it > on an etherpad. Will you help me capture the big picture there? I'd > like

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 not really designed to escalate rights on hundred

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] [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] [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 : &

[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

[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

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

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

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][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

[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] [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

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

<    1   2