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

2014-08-13 Thread Miguel Angel Ajo Pelayo
+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 slot for the

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

2014-08-19 Thread Miguel Angel Ajo Pelayo
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

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

2014-08-20 Thread Miguel Angel Ajo Pelayo
AM, shihanzhang wrote: hi Miguel Angel Ajo Pelayo! I agree with you and modify my spes, but I will also optimization the RPC from security group agent to neutron server. Now the modle is 'port[rule1,rule2...], port...', I will change it to 'port[sg1, sg2..]', this can reduce the size

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

2014-08-21 Thread Miguel Angel Ajo Pelayo
. On 07/02/2014 03:37 AM, shihanzhang wrote: hi Miguel Angel Ajo Pelayo! I agree with you and modify my spes, but I will also optimization the RPC from security group agent to neutron server. Now the modle is 'port[rule1,rule2...], port...', I will change it to 'port[sg1, sg2..]', this can

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

2014-08-25 Thread Miguel Angel Ajo Pelayo
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

2014-08-27 Thread Miguel Angel Ajo Pelayo
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

2014-08-27 Thread Miguel Angel Ajo Pelayo
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

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

2014-09-04 Thread Miguel Angel Ajo Pelayo
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

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

2014-09-05 Thread Miguel Angel Ajo Pelayo
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

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

2014-09-10 Thread Miguel Angel Ajo Pelayo
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: for future

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

2014-09-18 Thread Miguel Angel Ajo Pelayo
: 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 IpsetManager. I'd like to see this merged for J

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

2014-01-02 Thread Miguel Angel Ajo Pelayo
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

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

2014-01-22 Thread Miguel Angel Ajo Pelayo
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

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

2014-01-23 Thread Miguel Angel Ajo Pelayo
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

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

2014-01-29 Thread Miguel Angel Ajo Pelayo
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 mangel...@redhat.com To: OpenStack Development

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

2014-02-04 Thread Miguel Angel Ajo Pelayo
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

2014-02-04 Thread Miguel Angel Ajo Pelayo
- Original Message - From: Miguel Angel Ajo Pelayo mangel...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Tuesday, February 4, 2014 6:36:16 PM Subject: Re: [openstack-dev] [Neutron] backporting database

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

2014-02-05 Thread Miguel Angel Ajo Pelayo
: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 easy path. My aim when I started this backport was trying to scale out neutron-server

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

2014-02-06 Thread Miguel Angel Ajo Pelayo
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,

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

2014-02-12 Thread Miguel Angel Ajo Pelayo
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

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

2014-02-12 Thread Miguel Angel Ajo Pelayo
@lists.openstack.org Cc: openstack-stable-maint openstack-stable-ma...@lists.openstack.org 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

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

2014-02-20 Thread Miguel Angel Ajo Pelayo
I rebased the https://review.openstack.org/#/c/72576/ no-op change. - Original Message - From: Alan Pevec ape...@gmail.com To: openstack-stable-maint openstack-stable-ma...@lists.openstack.org Cc: OpenStack Development Mailing List openstack-dev@lists.openstack.org Sent: Tuesday,

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

2014-02-20 Thread Miguel Angel Ajo Pelayo
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. -

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

2014-03-05 Thread Miguel Angel Ajo Pelayo
- 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 hundreds of

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

2014-03-10 Thread Miguel Angel Ajo Pelayo
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 to

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

2014-03-11 Thread Miguel Angel Ajo Pelayo
On Mon, Mar 10, 2014 at 3:26 PM, Miguel Angel Ajo Pelayo mangel...@redhat.com wrote: 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

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

2014-06-19 Thread Miguel Angel Ajo Pelayo
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

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

2014-06-23 Thread Miguel Angel Ajo Pelayo
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

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

2014-06-26 Thread Miguel Angel Ajo Pelayo
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

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

2014-06-26 Thread Miguel Angel Ajo Pelayo
server can you help me to review my BP specs? At 2014-06-19 10:11:34, Miguel Angel Ajo Pelayo mangel...@redhat.com wrote: Hi it's a very interesting topic, I was getting ready to raise the same concerns about our security groups implementation, shihanzhang thank you

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

2014-07-01 Thread Miguel Angel Ajo Pelayo
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 [2].

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

2014-07-01 Thread Miguel Angel Ajo Pelayo
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 wrote: Hi it's a very interesting topic, I was getting ready to raise the same concerns about our security groups implementation, shihanzhang

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

2014-07-08 Thread Miguel Angel Ajo Pelayo
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] - Location for common third-party libs?

2014-07-09 Thread Miguel Angel Ajo Pelayo
+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

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

2014-07-10 Thread Miguel Angel Ajo Pelayo
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] Spec Proposal Deadline has passed, a note on Spec Approval Deadline

2014-07-14 Thread Miguel Angel Ajo Pelayo
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 12,

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

2014-07-23 Thread Miguel Angel Ajo Pelayo
+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

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

2014-10-23 Thread Miguel Angel Ajo Pelayo
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

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

2014-10-23 Thread Miguel Angel Ajo Pelayo
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

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

2014-10-24 Thread Miguel Angel Ajo Pelayo
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

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

2014-10-24 Thread Miguel Angel Ajo Pelayo
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 feedback!, Salvatore On 23 October 2014 14:03, Miguel Angel Ajo Pelayo mangel

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

2014-10-24 Thread Miguel Angel Ajo Pelayo
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

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

2014-10-24 Thread Miguel Angel Ajo Pelayo
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 recovered by

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

2014-10-24 Thread Miguel Angel Ajo Pelayo
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, while we'd need to hear from the stable team, I think it's

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

2014-10-30 Thread Miguel Angel Ajo Pelayo
Thank you very much, voted. - Original Message - On Thu, Oct 23, 2014 at 3:22 PM, Kyle Mestery mest...@mestery.com 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

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

2014-11-10 Thread Miguel Angel Ajo Pelayo
://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 from my Android phone using TouchDown (www.nitrodesk.com) -Original Message- From: Yuriy

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

2014-11-18 Thread Miguel Angel Ajo Pelayo
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

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

2015-02-26 Thread Miguel Angel Ajo Pelayo
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

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

2015-04-14 Thread Miguel Angel Ajo Pelayo
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

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

2015-04-14 Thread Miguel Angel Ajo Pelayo
On 10/4/2015, at 20:10, Kyle Mestery mest...@mestery.com wrote: On Fri, Apr 10, 2015 at 1:03 PM, Sean M. Collins s...@coreitpro.com mailto:s...@coreitpro.com wrote: We already tried to make Neutron the default with OVS - and the results were not good[1]. Operators who are currently not

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

2015-04-20 Thread Miguel Angel Ajo Pelayo
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

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

2015-04-24 Thread Miguel Angel Ajo Pelayo
Hi Armando Salvatore, On 23/4/2015, at 9:30, Salvatore Orlando sorla...@nicira.com wrote: On 23 April 2015 at 01:30, Armando M. arma...@gmail.com mailto:arma...@gmail.com wrote: On 22 April 2015 at 06:02, Miguel Angel Ajo Pelayo mangel...@redhat.com mailto:mangel...@redhat.com

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

2015-04-22 Thread Miguel Angel Ajo Pelayo
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

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

2015-04-22 Thread Miguel Angel Ajo Pelayo
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 amul...@redhat.com wrote: Just to offer some closure, it seems like

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

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

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

2015-04-28 Thread Miguel Angel Ajo Pelayo
On 24/4/2015, at 19:42, Armando M. arma...@gmail.com wrote: On 24 April 2015 at 01:47, Miguel Angel Ajo Pelayo mangel...@redhat.com mailto:mangel...@redhat.com wrote: Hi Armando Salvatore, On 23/4/2015, at 9:30, Salvatore Orlando sorla...@nicira.com mailto:sorla...@nicira.com

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

2015-04-15 Thread Miguel Angel Ajo Pelayo
to hop between 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 mangel...@redhat.com mailto:mangel...@redhat.com wrote: I saw Mathieu Rohon message on the mail list

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

2015-04-15 Thread Miguel Angel Ajo Pelayo
, at 10:00 , Miguel Angel Ajo Pelayo mangel...@redhat.com wrote: Ok, 1) #openstack-meeting-2 doesn’t exist (-alt is it) 2) and not only that we’re colliding the TWG meeting, but all the meeting rooms starting at UTC 14:30 are busy. While not preferable, I don’t mind overlapping

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

2015-04-15 Thread Miguel Angel Ajo Pelayo
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

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

2015-04-13 Thread Miguel Angel Ajo Pelayo
On 13/4/2015, at 3:53, Robert Collins robe...@robertcollins.net wrote: On 13 April 2015 at 13:09, Robert Collins robe...@robertcollins.net wrote: On 13 April 2015 at 12:53, Monty Taylor mord...@inaugust.com wrote: What we have in the gate is the thing that produces the artifacts that

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

2015-04-15 Thread Miguel Angel Ajo Pelayo
, Miguel Angel Ajo Pelayo mangel...@redhat.com 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. Tomorrow (Apr 15th / 14:00 UTC) It’s a been early since

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

2015-04-07 Thread Miguel Angel Ajo Pelayo
Hi Raghunath, feel free to look at: https://wiki.openstack.org/wiki/Meetings 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] [neutron] [QoS] QoS weekly meeting

2015-04-07 Thread Miguel Angel Ajo Pelayo
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] Being more aggressive with our defaults

2016-02-10 Thread Miguel Angel Ajo Pelayo
> 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

Re: [openstack-dev] [Horizon][Neutron][QoS]horizon angular network QoS panel

2016-02-25 Thread Miguel Angel Ajo Pelayo
Hi Masco!, Thanks a lot for working on this, I’m not following the [Horizon] tag and I missed this. I’ve added the Neutron and QoS tags. I will give it a try as soon as I can. Keep up the good work!, Cheers, Miguel Ángel. > On 10 Feb 2016, at 13:04, masco

Re: [openstack-dev] [all] A proposal to separate the design summit

2016-02-26 Thread Miguel Angel Ajo Pelayo
> On 26 Feb 2016, at 02:38, Sean McGinnis wrote: > > On Thu, Feb 25, 2016 at 04:13:56PM +0800, Qiming Teng wrote: >> Hi, All, >> >> After reading through all the +1's and -1's, we realized how difficult >> it is to come up with a proposal that makes everyone happy. When

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

2016-01-19 Thread Miguel Angel Ajo Pelayo
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][release] Releasing python-neutronclient 4.1.2?

2016-03-09 Thread Miguel Angel Ajo Pelayo
On Wed, Mar 9, 2016 at 4:16 PM, Doug Hellmann wrote: > Excerpts from Armando M.'s message of 2016-03-08 15:43:05 -0700: > > On 8 March 2016 at 15:07, Doug Hellmann wrote: > > > > > Excerpts from Armando M.'s message of 2016-03-08 12:49:16 -0700: > >

Re: [openstack-dev] [neutron] [nova] scheduling bandwidth resources / NIC_BW_KB resource class

2016-04-11 Thread Miguel Angel Ajo Pelayo
On Mon, Apr 11, 2016 at 1:46 PM, Jay Pipes <jaypi...@gmail.com> wrote: > Hi Miguel Angel, comments/answers inline :) > > On 04/08/2016 09:17 AM, Miguel Angel Ajo Pelayo wrote: >> >> Hi!, >> >> In the context of [1] (generic resource pools / scheduling

[openstack-dev] [neutron] [nova] scheduling bandwidth resources / NIC_BW_KB resource class

2016-04-08 Thread Miguel Angel Ajo Pelayo
Hi!, In the context of [1] (generic resource pools / scheduling in nova) and [2] (minimum bandwidth guarantees -egress- in neutron), I had a talk a few weeks ago with Jay Pipes, The idea was leveraging the generic resource pools and scheduling mechanisms defined in [1] to find the right

Re: [openstack-dev] [Neutron] OVS flow modification performance

2016-04-08 Thread Miguel Angel Ajo Pelayo
Hi, good that you're looking at this, You could create a lot of ports with this method [1] and a bit of extra bash, without the extra expense of instance RAM. [1] http://www.ajo.es/post/89207996034/creating-a-network-interface-to-tenant-network-in This effort is going to be still more

Re: [openstack-dev] [Neutron] Proposing Hirofumi Ichihara to Neutron Core Reviewer Team

2016-04-08 Thread Miguel Angel Ajo Pelayo
On Fri, Apr 8, 2016 at 11:28 AM, Ihar Hrachyshka wrote: > Kevin Benton wrote: > > I don't know if my vote counts in this area, but +1! >> > > What the gentleman said ^, +1. "me too ^" , +1 ! >

Re: [openstack-dev] [Neutron] OVS flow modification performance

2016-04-11 Thread Miguel Angel Ajo Pelayo
On Mon, Apr 11, 2016 at 11:40 AM, IWAMOTO Toshihiro <iwam...@valinux.co.jp> wrote: > At Fri, 8 Apr 2016 12:21:21 +0200, > Miguel Angel Ajo Pelayo wrote: >> >> Hi, good that you're looking at this, >> >> >> You could create a lot of ports with this meth

Re: [openstack-dev] [neutron] [nova] scheduling bandwidth resources / NIC_BW_KB resource class

2016-04-11 Thread Miguel Angel Ajo Pelayo
On Sun, Apr 10, 2016 at 10:07 AM, Moshe Levi <mosh...@mellanox.com> wrote: > > > > > *From:* Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com] > *Sent:* Friday, April 08, 2016 4:17 PM > *To:* OpenStack Development Mailing List (not for usage questions) < >

[openstack-dev] [nova][neutron] Routed networks / Generic Resource pools

2016-03-21 Thread Miguel Angel Ajo Pelayo
Hi, I was doing another pass on this spec, to see if we could leverage it as-is for QoS / bandwidth tracking / bandwidth guarantees, and I have a question [1] I guess I'm just missing some detail, but looking at the 2nd scenario, why wouldn't availability zones allow the same exactly if we

Re: [openstack-dev] [nova][neutron] Routed networks / Generic Resource pools

2016-03-21 Thread Miguel Angel Ajo Pelayo
On Mon, Mar 21, 2016 at 3:17 PM, Jay Pipes <jaypi...@gmail.com> wrote: > On 03/21/2016 06:22 AM, Miguel Angel Ajo Pelayo wrote: >> >> Hi, >> >> I was doing another pass on this spec, to see if we could leverage >> it as-is for QoS / bandwidth trackin

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

2016-04-27 Thread Miguel Angel Ajo Pelayo
Please add me to whatsapp or telegram if you use that : +34636522569 El 27/4/2016 12:50, majop...@redhat.com escribió: > Trying to find you folks. I was late > El 27/4/2016 12:04, "Paul Carver" escribió: > >> SFC team and anybody else dealing with flow

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

2016-04-27 Thread Miguel Angel Ajo Pelayo
Trying to find you folks. I was late El 27/4/2016 12:04, "Paul Carver" escribió: > SFC team and anybody else dealing with flow selection/classification (e.g. > QoS), > > I just wanted to confirm that we're planning to meet in salon C today > (Wednesday) to get lunch but

[openstack-dev] [neutron] [qos] gathering Friday 9:30

2016-04-28 Thread Miguel Angel Ajo Pelayo
Does governors ballroom in Hilton sound ok? We can move to somewhere else if necessary. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

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

2016-05-17 Thread Miguel Angel Ajo Pelayo
I agree, let's try to find a timeslot that works. using #openstack-neutron with the meetbot works, but it's going to generate a lot of noise. On Tue, May 17, 2016 at 11:47 AM, Ihar Hrachyshka wrote: > > > On 16 May 2016, at 15:47, Takashi Yamamoto >

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

2016-05-18 Thread Miguel Angel Ajo Pelayo
:10 PM, Kevin Benton <ke...@benton.pub> wrote: > Yeah, no meetings in #openstack-neutron please. It leaves us nowhere to > discuss development stuff during that hour. > > On Tue, May 17, 2016 at 2:54 AM, Miguel Angel Ajo Pelayo < > majop...@redhat.com> wrote: >

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

2016-05-06 Thread Miguel Angel Ajo Pelayo
Sounds good, I started by opening a tiny RFE, that may help in the organization of flows inside OVS agent, for inter operability of features (SFC, TaaS, ovs fw, and even port trunking with just openflow). [1] [2] [1] https://bugs.launchpad.net/neutron/+bug/1577791 [2]

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

2016-04-20 Thread Miguel Angel Ajo Pelayo
I think this is an interesting topic. What do you mean exactly by FC ? (feature chaining?) I believe we have three things to look at: (sorry for the TL) 1) The generalization of traffic filters / traffic classifiers. Having common models, some sort of common API or common API structure

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

2016-04-20 Thread Miguel Angel Ajo Pelayo
Sorry, I just saw, FC = flow classifier :-), I made it a multi purpose abrev. now ;) On Wed, Apr 20, 2016 at 2:12 PM, Miguel Angel Ajo Pelayo <majop...@redhat.com> wrote: > I think this is an interesting topic. > > What do you mean exactly by FC ? (feature chaining?) > > I

Re: [openstack-dev] [neutron] [nova] scheduling bandwidth resources / NIC_BW_KB resource class

2016-04-20 Thread Miguel Angel Ajo Pelayo
Inline update. On Mon, Apr 11, 2016 at 4:22 PM, Miguel Angel Ajo Pelayo <majop...@redhat.com> wrote: > On Mon, Apr 11, 2016 at 1:46 PM, Jay Pipes <jaypi...@gmail.com> wrote: >> On 04/08/2016 09:17 AM, Miguel Angel Ajo Pelayo wrote: [...] >> Yes, Nova's conducto

Re: [openstack-dev] [Neutron] OVS flow modification performance

2016-04-15 Thread Miguel Angel Ajo Pelayo
On Fri, Apr 15, 2016 at 7:32 AM, IWAMOTO Toshihiro <iwam...@valinux.co.jp> wrote: > At Mon, 11 Apr 2016 14:42:59 +0200, > Miguel Angel Ajo Pelayo wrote: >> >> On Mon, Apr 11, 2016 at 11:40 AM, IWAMOTO Toshihiro >> <iwam...@valinux.co.jp> wrote: >> > A

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

2016-04-21 Thread Miguel Angel Ajo Pelayo
g Flow Classifiers, while we need to make the full pipeline of features (externally pluggable) work together. > On Thu, Apr 21, 2016 at 12:58 PM, IWAMOTO Toshihiro <iwam...@valinux.co.jp> > wrote: >> >> At Wed, 20 Apr 2016 14:12:07 +0200, >> Miguel Angel Ajo Pelayo wrote

Re: [openstack-dev] [Neutron] Proposing Jakub Libosvar for testing core

2016-07-26 Thread Miguel Angel Ajo Pelayo
Ohhh, yikes, even though I'm late my vote would have been super +1!! On Tue, Jul 26, 2016 at 5:04 PM, Jakub Libosvar wrote: > On 26/07/16 16:56, Assaf Muller wrote: >> >> We've hit critical mass from cores interesting in the testing area. >> >> Welcome Jakub to the core

Re: [openstack-dev] [neutron] Neutron Port MAC Address Uniqueness

2016-08-12 Thread Miguel Angel Ajo Pelayo
RE: [openstack-dev] [neutron] Neutron Port MAC Address Uniqueness > > Miguel, > > I talked to our driver architect and according to him this is vendor > implementation (according to him this should work with Mellanox NIC) I need > to verify that this indeed working. &

Re: [openstack-dev] [neutron] Neutron Port MAC Address Uniqueness

2016-08-10 Thread Miguel Angel Ajo Pelayo
@moshe, any insight on this? I guess that'd depend on the nic internal switch implementation and how the switch ARP tables are handled there (per network, or global per switch). If that's the case for some sr-iov vendors (or all), would it make sense to have a global switch to create globally

Re: [openstack-dev] [octavia] Multi-node controller testing

2016-08-11 Thread Miguel Angel Ajo Pelayo
s://review.openstack.org/#/q/status:open+project:openstack/octavia+branch:master+topic:octavia_basic_lb_scenario [2] https://review.openstack.org/#/c/172199/66..75/.testr.conf > Stephen > > On Tue, Aug 9, 2016 at 5:40 AM, Miguel Angel Ajo Pelayo > <majop...@redhat.com> wrote: >&g

Re: [openstack-dev] [neutron][qos][drivers] RFE about QoS extended validation

2016-07-15 Thread Miguel Angel Ajo Pelayo
Oh yikes, I was "hit by a plane" (delay) plus a huge jet lag and didn't make it to the meeting, I'll be there next week. Thank you. On Tue, Jul 12, 2016 at 9:48 AM, Miguel Angel Ajo Pelayo <majop...@redhat.com> wrote: > I'd like to ask for some prioritization on this RFE [1],

[openstack-dev] [neutron][qos][drivers] RFE about QoS extended validation

2016-07-12 Thread Miguel Angel Ajo Pelayo
I'd like to ask for some prioritization on this RFE [1], since it's blocking one of the already existing RFEs for RFE (ingress bandwidth limiting), and we're trying to enhance the operator experience on the QoS service. It's been discussed on previous driver meetings, and it seems to have some

Re: [openstack-dev] [infra][neutron] - best way to load 8021q kernel module into cirros

2016-08-09 Thread Miguel Angel Ajo Pelayo
Answers inline. On Tue, Aug 9, 2016 at 8:08 AM, Antonio Ojea wrote: > What do you think about openwrt images? > > They are small, have documentation to build your custom images, have a > packaging system and have tons of networking features (ipv6, vlans, ...) , > also seems

Re: [openstack-dev] [octavia] Multi-node controller testing

2016-08-09 Thread Miguel Angel Ajo Pelayo
ck. What are the current options/tools we're considering? > > Cheers, > Lubosz Kosnik > Cloud Software Engineer OSIC > lubosz.kos...@intel.com > >> On Aug 8, 2016, at 7:04 AM, Miguel Angel Ajo Pelayo <majop...@redhat.com> >> wrote: >> >> Recently, I s

Re: [openstack-dev] [octavia] Multi-node controller testing

2016-08-09 Thread Miguel Angel Ajo Pelayo
Thank you!! :) On Mon, Aug 8, 2016 at 5:49 PM, Michael Johnson <johnso...@gmail.com> wrote: > Miguel, > > Thank you for your work here. I would support an effort to setup a > multi-node gate job. > > Michael > > > On Mon, Aug 8, 2016 at 5:04 AM, Miguel Angel

[openstack-dev] [octavia] Multi-node controller testing

2016-08-08 Thread Miguel Angel Ajo Pelayo
Recently, I sent a series of patches [1] to make it easier for developers to deploy a multi node octavia controller with n_controllers x [api, cw, hm, hk] with an haproxy in front of the API. Since this is the way the service is designed to work (with horizontal scalability in mind), and we want

Re: [openstack-dev] [neutron][networking-ovs-dpdk] conntrack security group driver with ovs-dpdk

2016-08-08 Thread Miguel Angel Ajo Pelayo
Awesome Sean!, Keep us posted!! :) On Sat, Aug 6, 2016 at 8:16 PM, Mooney, Sean K wrote: > Hi just a quick fyi, > > About 2 weeks ago I did some light testing with the conntrack security group > driver and the newly > > Merged upserspace conntrack support in ovs. >

Re: [openstack-dev] [infra][neutron] - best way to load 8021q kernel module into cirros

2016-08-08 Thread Miguel Angel Ajo Pelayo
The problem with the other projects image builds is that they are based for bigger systems, while cirros is an embedded-device-like image which boots in a couple of seconds. Couldn't we contribute to cirros to have such module load by default [1]? Or may be it's time for Openstack to build their

Re: [openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

2017-02-06 Thread Miguel Angel Ajo Pelayo
Jeremy Stanley wrote: > It's an option of last resort, I think. The next consistent flavor > up in most of the providers donating resources is double the one > we're using (which is a fairly typical pattern in public clouds). As > aggregate memory constraints are our primary quota limit, this

  1   2   >