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 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* 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 *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
