Open Stack

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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150507/7e58d920/attachment.html>