Re: [openstack-dev] [Neutron][QoS] Neutron QoS (Quality Of Service) update
On 7 May 2015 at 10:32, Miguel Ángel Ajo 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 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, > However i would like to see more people involved, especially more Neutron > experienced members because i believe we want to make the right decisions > and learn from past mistakes when making the API design. > > Feel free to update in the meeting wiki [1], and the spec review [2] > > *Topics* > > *API microversioning spec implications [3]* > QoS can benefit from this design, however some concerns were raised that > this will > only be available at mid L cycle. > I think a better view is needed how this aligns with the new QoS design and > any feedback/recommendation is use full > > I guess an strategy here could be: go on with an extension, and translate > that into > an experimental API once micro versioning is ready, then after one cycle > we could > “graduate it” to get versioned. > Indeed. I think the guy who wrote the spec mentioned how to handle extensions which are in the pipeline already, and has a kind word for QoS in particular. > > *Changes to the QoS API spec: scoping into bandwidth limiting* > At this point the concentration is on the API and implementation > of bandwidth limiting. > > However it is important to keep the design easily extensible for some next > steps > like traffic classification and marking > *.* > > This is important for architecting your data model, RPC interfaces, and to some extent even the control plane. >From a user perspective (and hence API design) the question to ask would be whether a generic QoS API (for instance based on generic QoS policies which might have a different nature) is better than an explicit ones - where you would have distinct URIs for rate limiting, traffic shaping, marking, etc. I am not sure of what could be the right answer here. I tend to think distinct URIs are more immediate to use. On the other hand users will have to learn more APIs, but even with a generic framework users will have to learn how to create policies for different types of QoS policies. > > *Changes to the QoS API spec: modeling of rules (class hierarchy) > (Guarantee split out)* > There is a QoSPolicy which is composed of different QoSRules, there is > a discussion of splitting the rules into different types like > QoSRule. > (This in order to support easy extension of this model by adding new type > of rules which extend the possible parameters) > > Plugins can then separate optional aspects into separate rules. > Any feedback on this approach is appreciated. > > *Discuss multiple API end points (per rule type) vs single* > > > here, the topic name was incorrect, where I said API end points, we were > meaning URLs or REST resources.. (thanks Irena for the correction) > So probably my previous comment applies here as well. > > > In summary this means that in the above model, do we want to support > /v1/qosrule/.. or /v1/qosrule/ API's > I think the consensus right now is that the later is more flexible. > > Miguel is also checking the possibility of using something like: > /v1/qosrule/type/... kind of parsing > Feedback is desired here too :) > > *Traffic Classification considerations* > The idea right now is to extract the TC classification to another data > model > and attach it to rule > that way no need to repeat same filters for the same kind of traffic. > > Didn't you say you were going to focus on rate limiting? ;) > > Of course we need to consider here what it means to "update" a classifier > and not to introduce too much dependencies > > About this, the intention is not to fully model this, or to include it in > the data model now, > but try to see how could we do it in future iterations and see if it fits > the current data model > and APIs we’re proposing. > Can classifier management be considered an admin mgmt feature like instance flavour? > > > > *The ingress vs egress differences and issues* > Egress bandwidth limiting is much more use full and supported, > There is still doubt on the support of Ingress bandwidth limiting in OVS, > anyone > that knows if Ingress QoS is supported in OVS we want your feedback :) > > I do not think so, but don't take my word for granted. You can ping somebody in #openvswitch or post to ovs-disc...@openvswitch.org > (For example implementing OF1.3 Metering spec) > > Thanks all (Miguel, Sean or anyone else, please update this if i forgot > anything) > > [1] https://wiki.openstack.org/wiki/Meetings/QoS > [2] https://review.openstack.org/#/c/88599/ > [3] https://review.openstack.org/#/c/136760/
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 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, > However i would like to see more people involved, especially more Neutron > experienced members because i believe we want to make the right decisions and > learn from past mistakes when making the API design. > > Feel free to update in the meeting wiki [1], and the spec review [2] > > Topics > > API microversioning spec implications [3] > QoS can benefit from this design, however some concerns were raised that this > will > only be available at mid L cycle. > I think a better view is needed how this aligns with the new QoS design and > any feedback/recommendation is use full I guess an strategy here could be: go on with an extension, and translate that into an experimental API once micro versioning is ready, then after one cycle we could “graduate it” to get versioned. > > > Changes to the QoS API spec: scoping into bandwidth limiting > At this point the concentration is on the API and implementation > of bandwidth limiting. > > However it is important to keep the design easily extensible for some next > steps > like traffic classification and marking. > > Changes to the QoS API spec: modeling of rules (class hierarchy) (Guarantee > split out) > There is a QoSPolicy which is composed of different QoSRules, there is > a discussion of splitting the rules into different types like QoSRule. > (This in order to support easy extension of this model by adding new type > of rules which extend the possible parameters) > > Plugins can then separate optional aspects into separate rules. > Any feedback on this approach is appreciated. > > Discuss multiple API end points (per rule type) vs single here, the topic name was incorrect, where I said API end points, we were meaning URLs or REST resources.. (thanks Irena for the correction) > > In summary this means that in the above model, do we want to support > /v1/qosrule/.. or /v1/qosrule/ API's > I think the consensus right now is that the later is more flexible. > > Miguel is also checking the possibility of using something like: > /v1/qosrule/type/... kind of parsing > Feedback is desired here too :) > > Traffic Classification considerations > The idea right now is to extract the TC classification to another data model > and attach it to rule > that way no need to repeat same filters for the same kind of traffic. > > Of course we need to consider here what it means to "update" a classifier > and not to introduce too much dependencies About this, the intention is not to fully model this, or to include it in the data model now, but try to see how could we do it in future iterations and see if it fits the current data model and APIs we’re proposing. > > > The ingress vs egress differences and issues > Egress bandwidth limiting is much more use full and supported, > There is still doubt on the support of Ingress bandwidth limiting in OVS, > anyone > that knows if Ingress QoS is supported in OVS we want your feedback :) > (For example implementing OF1.3 Metering spec) > > Thanks all (Miguel, Sean or anyone else, please update this if i forgot > anything) > > [1] https://wiki.openstack.org/wiki/Meetings/QoS > [2] https://review.openstack.org/#/c/88599/ > [3] https://review.openstack.org/#/c/136760/ > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > (mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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, However i would like to see more people involved, especially more Neutron experienced members because i believe we want to make the right decisions and learn from past mistakes when making the API design. Feel free to update in the meeting wiki [1], and the spec review [2] *Topics* *API microversioning spec implications [3]* QoS can benefit from this design, however some concerns were raised that this will only be available at mid L cycle. I think a better view is needed how this aligns with the new QoS design and any feedback/recommendation is use full *Changes to the QoS API spec: scoping into bandwidth limiting* At this point the concentration is on the API and implementation of bandwidth limiting. However it is important to keep the design easily extensible for some next steps like traffic classification and marking *.* *Changes to the QoS API spec: modeling of rules (class hierarchy) (Guarantee split out)* There is a QoSPolicy which is composed of different QoSRules, there is a discussion of splitting the rules into different types like QoSRule. (This in order to support easy extension of this model by adding new type of rules which extend the possible parameters) Plugins can then separate optional aspects into separate rules. Any feedback on this approach is appreciated. *Discuss multiple API end points (per rule type) vs single* In summary this means that in the above model, do we want to support /v1/qosrule/.. or /v1/qosrule/ API's I think the consensus right now is that the later is more flexible. Miguel is also checking the possibility of using something like: /v1/qosrule/type/... kind of parsing Feedback is desired here too :) *Traffic Classification considerations* The idea right now is to extract the TC classification to another data model and attach it to rule that way no need to repeat same filters for the same kind of traffic. Of course we need to consider here what it means to "update" a classifier and not to introduce too much dependencies *The ingress vs egress differences and issues* Egress bandwidth limiting is much more use full and supported, There is still doubt on the support of Ingress bandwidth limiting in OVS, anyone that knows if Ingress QoS is supported in OVS we want your feedback :) (For example implementing OF1.3 Metering spec) Thanks all (Miguel, Sean or anyone else, please update this if i forgot anything) [1] https://wiki.openstack.org/wiki/Meetings/QoS [2] https://review.openstack.org/#/c/88599/ [3] https://review.openstack.org/#/c/136760/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
