Open Stack

On 7 May 2015 at 10:32, Miguel Ángel Ajo <majopela at redhat.com> 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 ovs-discuss at 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/
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150508/11f0a3e8/attachment.html>