On 7 May 2015 at 10:32, Miguel Ángel Ajo <[email protected]> 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 > QoS<Type>Rule. > (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/qos<type>rule/ 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 [email protected] > (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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
