[openstack-dev] [neutron] QoS IRC meeting

Hi, I have to cancel todays Neutron QoS IRC meeting. If You have something related to QoS that You want to talk about, please catch me on openstack-neutron irc channel. — Best regards Slawek Kaplonski sla...@kaplonski.pl

[openstack-dev] [neutron] QoS meeting cancelled, next meeting 29/08/2017

Hello: Yesterday by mistake I didn't send an email saying the QoS meeting was cancelled. During this weeks, our focus are in the RC and solving possible bugs. Next meeting (no excuses) will be on 29/08/2017. Regards. __

[openstack-dev] [Neutron][QoS] No QoS meeting this week

Hello, As many of people are probably on summit we will cancel this week QoS meeting. Next meeting will be at 23.05.2017. Pozdrawiam / Best regards Sławek Kapłoński sla...@kaplonski.pl __ OpenStack Development Mailing List

[openstack-dev] [neutron][qos] qos service enabling in test env

Hi neutrinos, I reported a bug in plugin been sending stale data to mechanism driver [1]. Which was fixed by [2]. I am trying to write a test case as well, but seems like I am unable to see success for enabling qos service properly in test environment In

Re: [openstack-dev] [Neutron][qos] Question about behavior expectations if network policy is set

nvswitch/agent/ovs_neutron_agent.py#L427-L437 > > -Original Message- > From: Michael Micucci [mailto:micu...@midokura.com] > Sent: Friday, September 2, 2016 8:28 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Neutron][qos] Question about behavior > expec

Re: [openstack-dev] [Neutron][qos] Question about behavior expectations if network policy is set

, September 2, 2016 8:28 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][qos] Question about behavior expectations if network policy is set Hey all, Quick question: If I have a network and a port, and neither has any QOS policy set, and then I change the network to set

Re: [openstack-dev] [Neutron][qos] Question about behavior expectations if network policy is set

Hey all, Quick question: If I have a network and a port, and neither has any QOS policy set, and then I change the network to set the qos_policy_id, should this new QOS policy affect traffic on the already-created port? In other words, is this a network default for future ports (like with

Re: [openstack-dev] [Neutron][qos] Question about behavior expectations if network policy is set

Hey all, Quick question: If I have a network and a port, and neither has any QOS policy set, and then I change the network to set the qos_policy_id, should this new QOS policy affect traffic on the already-created port? In other words, is this a network default for future ports (like with

Re: [openstack-dev] [neutron][qos]

Ofer Ben-Yacov wrote: Hi. I was asked to look for a solution / develop traffic control component. The idea is that provider / tenant will be able to enforce rate limit, do traffic shaping and prioritize traffic from several VMs (policy) - not like the qos in

[openstack-dev] [Neutron][QoS] Question about QoS bandwidth limit rule

Hi, all I had tested Neutron QoS function, we can apply the bandwidth limit rule for instance's port, but router ports are excluded from bandwidth policy. In Neutron ovs agent, we can see the ovs-vsctl command set ingress_policing_rate and ingress_policing_burst, instance apply to "qvo" device,

[openstack-dev] [neutron][qos]

Hi. I was asked to look for a solution / develop traffic control component. The idea is that provider / tenant will be able to enforce rate limit, do traffic shaping and prioritize traffic from several VMs (policy) - not like the qos in neutron now which can do this on single VM port. My initial

Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth assurance

- From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] Sent: Monday, July 18, 2016 11:53 AM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth assurance Rodolfo <

Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth assurance

Rodolfo wrote: Hello: I’m working in the egress minimum bandwidth assurance qos policy rule. I made a POC using the following architecture: - Every time a new rule is created and assigned to a port: o A new queue is created in OVS. o

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

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 wrote: > I'd like to ask for some prioritization on this RFE [1], since it's blocking

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

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] [neutron][qos] Egress minimum bandwidth assurance

ct: Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth assurance Hello: Ichihara, thank you for your answer. It was just a test to find out how to setup correctly the egress traffic shaping. I was facing this situation and I found the problem: I was using bridges with datapath_type = netdev, i

Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth assurance

(not for usage questions) <openstack-dev@lists.openstack.org> *Subject:* Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth assurance On 2016/06/15 18:54, Alonso Hernandez, Rodolfo wrote: Hello: Context: try to develop a driver for this feature in OVS. During the las

[openstack-dev] [neutron][qos] QoS for floatingip

Hi, all. As far as I know, currently networking QoS aims to "qvo" devices which attached to the internal ovs bridge. I think we need a solution to control floatingip's rate limit. Do we have any plan to implement rate limit for floatingip? I think that we can use TC to implement it.

Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth assurance

] Sent: Tuesday, June 21, 2016 10:27 AM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth assurance On 2016/06/15 18:54, Alonso Hernandez, Rodolfo wrote: Hello: Contex

Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth assurance

On 2016/06/15 18:54, Alonso Hernandez, Rodolfo wrote: Hello: Context: try to develop a driver for this feature in OVS. During the last week I’ve been testing several scenarios to make a POC of this feature. Scenario 1: 3 VM connected to br-int, sending traffic through br-physical to

[openstack-dev] [neutron][qos] Egress minimum bandwidth assurance

Hello: Context: try to develop a driver for this feature in OVS. During the last week I’ve been testing several scenarios to make a POC of this feature. Scenario 1: 3 VM connected to br-int, sending traffic through br-physical to other host (an external physical machine). The first VM will

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

Hi Miguel, Nate and I have a conflicting meeting, about FWaaS, at 9:30. I’m reaching out to him now to see how we might fan out to get coverage. Margaret -- Margaret Frances Eng 4, Prodt Dev Engineering > On Apr 28, 2016, at 6:02 PM, Miguel Angel Ajo Pelayo > wrote:

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

Yup,+1 On Apr 29, 2016 04:19, "Shaughnessy, David" wrote: > Sounds good, +1. > > > > *From:* Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com] > *Sent:* Thursday, April 28, 2016 11:03 PM > *To:* OpenStack Development Mailing List (not for usage questions) < >

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

Sounds good, +1. From: Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com] Sent: Thursday, April 28, 2016 11:03 PM To: OpenStack Development Mailing List (not for usage questions) ; Nate Johnston ; Margaret Frances

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

Does governors ballroom in Hilton sound ok? We can move to somewhere else if necessary. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

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

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

Correct, thanks Moshe. One of the first proposals is probably changing the periodicity of the meeting to 2-weeks instead if every week. We could vote on that by the end of the meeting, depending on how things go. And of course, we could change that back to 1-week later in the cycle as

[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

Miguel Angel Ajo wrote: 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. I think you

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

Just to add more details about the when and where :) We will have a weekly meeting on Wednesday at 1400 UTC in #openstack-meeting-3 http://eavesdrop.openstack.org/#Neutron_QoS_Meeting Thanks, Moshe Levi. > -Original Message- > From: Ihar Hrachyshka

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

Paul Carver wrote: On 11/12/2015 3:50 PM, Ihar Hrachyshka wrote: All I am saying is that IF we merge some classifier API into neutron core and start using it for core, non-experimental, features, we cannot later move to some newer version of this API [that you will

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

German wrote: Ihar, The Service Group API will be added to FWaaS only and remain experimental in M. If the community finds it useful for other areas it can be added to Neutron core once it is matures. I think incubating it inside FWaaS will give us the

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

Ihar, The Service Group API will be added to FWaaS only and remain experimental in M. If the community finds it useful for other areas it can be added to Neutron core once it is matures. I think incubating it inside FWaaS will give us the velocity to iterate quickly and once it matures a

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

On Fri, Nov 13, 2015 at 01:53:49AM EST, Paul Carver wrote: > On 11/3/2015 1:03 PM, Sean M. Collins wrote: > >Anyway, the code is currently up on GitHub - I just threw it on there > >because I wanted to scratch my hacking itch quickly. > > > >https://github.com/sc68cal/neutron-classifier > > > >

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

Cathy Zhang wrote: Agree with Paul and Louis. The networking-sfc repo should be preserved to support the service function chain functionality. Flow classifier is just needed to specify what flows will go through the service port chain. The flow classifier API is

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

On 11/12/2015 3:50 PM, Ihar Hrachyshka wrote: All I am saying is that IF we merge some classifier API into neutron core and start using it for core, non-experimental, features, we cannot later move to some newer version of this API [that you will iterate on] without leaving a huge pile of

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

On 11/3/2015 1:03 PM, Sean M. Collins wrote: Anyway, the code is currently up on GitHub - I just threw it on there because I wanted to scratch my hacking itch quickly. https://github.com/sc68cal/neutron-classifier Sean, How much is needed to turn your models into something runnable to the

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

, 2015 2:33 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers Paul, Agree completely that the networking-sfc repo should be preserved as it includes functionality beyond that of just

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

On 11/10/2015 8:30 AM, Sean M. Collins wrote: On Mon, Nov 09, 2015 at 07:58:34AM EST, Jay Pipes wrote: 2) Keep the security-group API as-is to keep outward compatibility with AWS. Create a single, new service-groups and service-group-rules API for L2 to L7 traffic classification using mostly

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

. - Louis -Original Message- From: Paul Carver [mailto:pcar...@paulcarver.us] Sent: Wednesday, November 11, 2015 1:07 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers On 11/10/2015

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

Sean and Mickey +1 As much as I like us using the same API to create classifiers (users only need to learn one way) I think for the short term we should work with our own constructs and rely on a common data model. That will allow us to iterate faster on the REST API level and not have

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

On Mon, Nov 09, 2015 at 07:58:34AM EST, Jay Pipes wrote: > In short, my preference, in order, would be: > > 1) Enhance/evolve the existing security-groups and security-group-rules API > in Neutron to support more generic classification of traffic from L2 to L7, > using mostly the modeling that

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

On 11/03/2015 12:19 PM, Ihar Hrachyshka wrote: Now, I don't think that we need two APIs for the same thing. I would be glad if we instead converge on a single API, making sure all cases are covered. In the end, the feature is just a building block for other features, like fwaas, security groups,

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

il.com> Date: 11/09/2015 05:04AM Subject: Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers On 11/03/2015 12:19 PM, Ihar Hrachyshka wrote: > Now, I don't think that we need two APIs for the same thing. I would > be glad if we instead converge on a singl

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

On Tue, Nov 03, 2015 at 02:08:26PM EST, Vikram Choudhary wrote: > Thanks for all your efforts Sean. > > I was actually thinking a separate IRC for this effort would be great and > will help all the interested people to come together and develop. > > Any thoughts on this? Unless it becomes super

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

Sean M. Collins wrote: Hi Ihar, This sounds good. I actually had a draft e-mail that I've been saving until I got back, that may be relevant. Some contributors met on Friday to discuss the packet classification framework, mostly centered around just building a reusable

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

I am fine with this! -Original Message- From: Sean M. Collins [mailto:s...@coreitpro.com] Sent: 04 November 2015 14:28 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers On Tue, Nov

[openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, on fwaas design session in Tokyo it was pointed out that for new fwaas API we may want to use service groups [1] that were approved but never merged. As far as I can tell, service groups are designed to catch several criteria to describe a

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

Hi Ihar, This sounds good. I actually had a draft e-mail that I've been saving until I got back, that may be relevant. Some contributors met on Friday to discuss the packet classification framework, mostly centered around just building a reusable library that can be shared among multiple

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

Thanks for all your efforts Sean. I was actually thinking a separate IRC for this effort would be great and will help all the interested people to come together and develop. Any thoughts on this? Thanks Vikram On Nov 3, 2015 11:54 PM, "Sean M. Collins" wrote: > I made a

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

I made a very quick attempt to jot down my thoughts about how it could be used. It's based off what I proposed in https://review.openstack.org/238812, and is my attempt to take that review and use SQLAlchemy to make it actually work.

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

I've pushed the patch into the merge queue now. Any nits people find at this point we'll address post merge. Awesome work QoS team! On Mon, Aug 17, 2015 at 9:56 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 So the patch in question sit there

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 So the patch in question sit there for some time, and honestly, I haven't seen much interest from reviewers to take a look at it, apart from Assaf who played with the code and reported a bunch of minor issues . I think Kyle's plan was to wait until

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 is ready, I

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/13/2015 06:54 AM, Andreas Jaeger wrote: On 08/12/2015 09:55 PM, Ihar Hrachyshka wrote: Hi all, with great pleasure, I want to request a coordinated review for merging feature/qos branch back to master:

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

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

On 08/12/2015 09:55 PM, Ihar Hrachyshka wrote: Hi all, with great pleasure, I want to request a coordinated review for merging feature/qos branch back to master: https://review.openstack.org/#/c/212170/ Great! Please send also a patch for project-config to remove the special handling of

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, with great pleasure, I want to request a coordinated review for merging feature/qos branch back to master: https://review.openstack.org/#/c/212170/ Since it's a merge patch, gerrit fails to show the whole diff that it introduces into

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

If you want a quick visual diff of this, you can click on Files changed here: https://github.com/openstack/neutron/compare/feature/qos On Wed, Aug 12, 2015 at 12:55 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, with great pleasure, I

Re: [openstack-dev] [neutron][qos][ml2] extensions swallow exceptions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/04/2015 08:41 PM, Robert Kukura wrote: The process_[create|update]_resource() extension driver methods are intended to validate user input. Exceptions raised by these need to be returned to users so they know what they did wrong. I am not

[openstack-dev] [neutron][qos][ml2] extensions swallow exceptions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, in feature/qos, we use ml2 extension drivers to handle additional qos_policy_id field that can be provided thru API: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2 /extensions/qos.py?h=feature/qos What we do in

Re: [openstack-dev] [neutron][qos][ml2] extensions swallow exceptions

Don't know why subject wasn't set automatically.. On Tue, Aug 4, 2015 at 3:30 PM, Mike Kolesnik mkole...@redhat.com wrote: On Tue, Aug 4, 2015 at 1:02 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, in feature/qos, we use ml2

Re: [openstack-dev] [neutron][qos][ml2] extensions swallow exceptions

There is this review[1] trying to solve exactly what you¹re asking for. I think it makes sense for the exceptions to be propagated all the way back to the user instead of swallowing them and then roll back the transaction. Does it even make sense to continue after a failure? [1]

Re: [openstack-dev] [neutron][qos][ml2] extensions swallow exceptions

The process_[create|update]_resource() extension driver methods are intended to validate user input. Exceptions raised by these need to be returned to users so they know what they did wrong. These exceptions should not be logged as anything higher than info level, since user errors generally

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 finishing the

[openstack-dev] [neutron][qos] how we get back into master

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, as you probably know, QoS feature is on horizon for Liberty and uses a separate feature/qos branch. It's expected that after it's complete, the branch is merged back into master. Note that it will probably be the first (or the second, if

[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

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

questions) Cc: lionel.zer...@huawei.com; Derek Chamorro (dechamor); Eran Gampel Subject: Re: [openstack-dev] [Neutron] [QOS] Request for Additional QoS capabilities If fwaas code is at the router level, it would seem that null routing might be one method of handling ddos, making fwaas

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

Today we were thinking a little bit about the patches work we have to do/we have on flight. And their dependencies. http://fileshare.ajo.es/QoS/P6290039.jpg This is how it looks like (probably missing stuff). Notation: * Green are single patches (in some cases those can/should be divided) *

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

Thanks for arranging this Miguel. Looking forward to contribute in the best way we can  On 26-Jun-2015 3:33 pm, Miguel Angel Ajo mangel...@redhat.com 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

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

. John From: Gal Sagie [mailto:gal.sa...@gmail.com] Sent: Tuesday, June 23, 2015 2:43 PM To: OpenStack Development Mailing List (not for usage questions) Cc: lionel.zer...@huawei.com; Derek Chamorro (dechamor); Eran Gampel Subject: Re: [openstack-dev] [Neutron] [QOS] Request for Additional QoS

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

*To:* OpenStack Development Mailing List (not for usage questions) *Cc:* lionel.zer...@huawei.com; Derek Chamorro (dechamor); Eran Gampel *Subject:* Re: [openstack-dev] [Neutron] [QOS] Request for Additional QoS capabilities Hi John, Sorry for the delayed response as i was on vacation

[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

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

:* Wednesday, June 17, 2015 12:45 PM *To:* OpenStack Development Mailing List (not for usage questions) *Cc:* lionel.zer...@huawei.com; Derek Chamorro (dechamor); Eran Gampel *Subject:* Re: [openstack-dev] [Neutron] [QOS] Request for Additional QoS capabilities Hi John, We were trying

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

] Sent: Wednesday, June 17, 2015 12:45 PM To: OpenStack Development Mailing List (not for usage questions) Cc: lionel.zer...@huawei.com; Derek Chamorro (dechamor); Eran Gampel Subject: Re: [openstack-dev] [Neutron] [QOS] Request for Additional QoS capabilities Hi John, We were trying to push

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

(not for usage questions) Cc: lionel.zer...@huawei.com; Derek Chamorro (dechamor); Eran Gampel Subject: Re: [openstack-dev] [Neutron] [QOS] Request for Additional QoS capabilities Hi John, We were trying to push a very similar spec to enhance the security group API, we covered both DDoS case and another

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

Hi John, We were trying to push a very similar spec to enhance the security group API, we covered both DDoS case and another use case for brute force prevention (We did a research to identify common protocols login behaviour in order to identify brute force attacks using iptables) and even some

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

Hello everyone: I would like to test the waters on some new functionality we think is needed to protect OpenStack deployments from some overload situations due to an excessive user or DDOS scenario. We wrote this up in the style of an RFE. Please let us know your thoughts and we can

Re: [openstack-dev] [Neutron][QoS] Neutron QoS (Quality Of Service) update

On 7 May 2015 at 10:32, Miguel Ángel Ajo majop...@redhat.com wrote: Gal, thank you very much for the update to the list, I believe it’s very helpful, I’ll add some inline notes. On Thursday, 7 de May de 2015 at 8:51, Gal Sagie wrote: Hello All, I think that the Neutron QoS effort is

[openstack-dev] [Neutron][QoS] Neutron QoS (Quality Of Service) Update

Hello All, I think that the Neutron QoS effort is progressing into critical point and i asked Miguel if i could post an update on our progress. First, i would like to thank Sean and Miguel for running this effort and everyone else that is involved, i personally think its on the right track,

Re: [openstack-dev] [Neutron][QoS] Neutron QoS (Quality Of Service) update

Gal, thank you very much for the update to the list, I believe it’s very helpful, I’ll add some inline notes. On Thursday, 7 de May de 2015 at 8:51, Gal Sagie wrote: Hello All, I think that the Neutron QoS effort is progressing into critical point and i asked Miguel if i could post an

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

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] service-plugin or not discussion

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

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

On 24 April 2015 at 01:47, Miguel Angel Ajo Pelayo mangel...@redhat.com wrote: 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 wrote: On 22 April 2015 at 06:02, Miguel Angel Ajo Pelayo

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

On 23 April 2015 at 01:30, Armando M. arma...@gmail.com wrote: On 22 April 2015 at 06:02, Miguel Angel Ajo Pelayo mangel...@redhat.com wrote: 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

[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

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

On 22 April 2015 at 06:02, Miguel Angel Ajo Pelayo mangel...@redhat.com wrote: 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. My apologies if I was unable to join,

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/20/2015 12:20 PM, Miguel Angel Ajo Pelayo wrote: 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

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

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

Hi, This week neutron QoS meeting will take place on Tuesday, April 21 at 14:00 UTC on #openstack-meeting-3. Next week, the meeting is back to its original slot: Wed at 14:00 UTC on #openstack-meeting-3. Please join if you are interested.

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

On Mon, Apr 20, 2015 at 8:44 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/20/2015 12:20 PM, Miguel Angel Ajo Pelayo wrote: Thank you Irena, I believe this last minute change deserves an explanation, I asked Irena to write to the

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

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] QoS weekly meeting

@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, April 7, 2015 12:19 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting Hi Miguel

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

mailto:openstack-dev@lists.openstack.org Date: Tuesday, April 7, 2015 12:19 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting Hi

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

On Apr 15, 2015, 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

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

Ok, during today’s preliminary meeting we talked about moving to #openstack-meeting-3, and we’re open to move -30m the meeting if it’s ok for everybody, to only partly overlap with the TWG, yet we could stay at 14:00 UTC for now. I have updated both wikis to reflect the meeting room change (to

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

@lists.openstack.org Subject: Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting Hi Miguel, Both time slots work for me. Thanks for rekindling this effort. Thanks, Sandhya From: Miguel Ángel Ajo majop...@redhat.com Reply-To: OpenStack Development Mailing List (not for usage questions

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

mailto:openstack-dev@lists.openstack.org Date: Tuesday, April 7, 2015 12:19 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting Hi Miguel

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

List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting Hi Miguel, Both time slots work for me. Thanks for rekindling this effort. Thanks, Sandhya From: Miguel Ángel Ajo

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

@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, April 7, 2015 12:19 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting Hi

  1   2   >