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 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) > > 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. > > 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
