<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 7 May 2015 at 10:32, Miguel Ángel Ajo <span dir="ltr"><<a href="mailto:majopela@redhat.com" target="_blank">majopela@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="font-family:Helvetica;font-size:15px">Gal, thank you very much for the update to the list, I believe it’s very helpful,</div><div style="font-family:Helvetica;font-size:15px">I’ll add some inline notes.</div>
<p style="color:rgb(160,160,168)">On Thursday, 7 de May de 2015 at 8:51, Gal Sagie wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px">
<span><div><div><div dir="ltr"><div><div><div><div><div>Hello All,<br><br></div>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.<br></div><br></div>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.<br><br></div>Feel free to update in the meeting wiki [1], and the spec review [2]<br></div><br><div><b><u>Topics</u></b><br><br></div><div><span><u>API microversioning spec implications [3]</u><br></span></div><div><span>QoS can benefit from this design, however some concerns were raised that this will<br></span></div><div><span>only be available at mid L cycle.<br></span></div><div><span>I think a better view is needed how this aligns with the new QoS design and<br></span></div><div><span>any feedback/recommendation is use full<br></span></div></div></div></div></span></blockquote><div>I guess an strategy here could be: go on with an extension, and translate that into</div><div>an experimental API once micro versioning is ready, then after one cycle we could</div><div>“graduate it” to get versioned.</div></blockquote><div><br></div><div>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. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px"><span><div><div><div dir="ltr"><div><span></span></div><div><br><span><span><u>Changes to the QoS API spec: scoping into bandwidth limiting</u><br>At this point the concentration is on the API and implementation<br></span></span></div><div><span><span>of bandwidth limiting.<br><br></span></span></div><div><span><span>However it is important to keep the design easily extensible for some next steps<br></span></span></div><div><span><span>like traffic classification and marking<b>.<br></b></span></span></div></div></div></div></span></blockquote></blockquote><div>This is important for architecting your data model, RPC interfaces, and to some extent even the control plane.</div><div>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.</div><div><br></div><div>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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px"><span><div><div><div dir="ltr"><div><br><span><span><span><u>Changes to the QoS API spec: modeling of rules (class hierarchy) (Guarantee split out)</u><br></span></span></span></div><div><span><span><span>There is a QoSPolicy which is composed of different QoSRules, there is<br></span></span></span></div><div><span><span><span>a discussion of splitting the rules into different types like QoS<Type>Rule.<br></span></span></span></div><div><span><span><span>(This in order to support easy extension of this model by adding new type <br></span></span></span></div><div><span><span><span>of rules which extend the possible parameters)<br><br></span></span></span></div><div><span><span><span>Plugins can then<b> </b></span></span></span><span><span><span></span></span></span>separate optional aspects into separate rules.<br></div><div>Any feedback on this approach is appreciated.<br></div><div><br><span><u>Discuss multiple API end points (per rule type) vs single</u></span></div></div></div></div></span></blockquote><div><br></div><div><span style="font-size:15px">here, the topic name was incorrect, where I said API end points, we were</span></div><div><span style="font-size:15px">meaning URLs or REST resources.. (thanks Irena for the correction)</span></div></blockquote><div><br></div><div>So probably my previous comment applies here as well. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><br></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px"><span><div><div><div dir="ltr"><div><span><br></span></div><div><span>In summary this means that in the above model, do we want to support<br></span></div><div><span>/v1/qosrule/.. or /v1/qos<type>rule/ API's<br></span></div><div><span>I think the consensus right now is that the later is more flexible.<br><br></span></div><div><span>Miguel is also checking the possibility of using something like:<br></span></div><div><span>/v1/qosrule/type/... kind of parsing<br>Feedback is desired here too :)</span><b><br></b></div><div><span><span></span></span></div><div><span><span></span></span><br><span><span><u>Traffic Classification considerations</u><br></span></span></div><div><span><span>The idea right now is to extract the TC classification to another data model<br></span></span></div><div><span><span>and attach it to rule<br></span></span></div><div><span><span>that way </span></span>no need to repeat same filters for the same kind of traffic.<br></div></div></div></div></span></blockquote></blockquote><div><br></div><div>Didn't you say you were going to focus on rate limiting? ;) </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px"><span><div><div><div dir="ltr"><div><br></div><div>Of course we need to consider here what it means to "update" a classifier<br></div><div>and not to introduce too much dependencies<br></div></div></div></div></span></blockquote></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><span style="font-size:15px">About this, the intention is not to fully model this, or to include it in the data model now,</span></div><div><span style="font-size:15px">but try to see how could we do it in future iterations and see if it fits the current data model</span></div><div><span style="font-size:15px">and APIs we’re proposing.</span></div></blockquote><div><br></div><div>Can classifier management be considered an admin mgmt feature like instance flavour? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div> </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px"><span><div><div><div dir="ltr"><div></div><div><br><span><u><span><span>The ingress vs egress differences and issues</span></span></u><b><br></b>Egress bandwidth limiting is much more use full and supported,<br></span></div><div><span>There is still doubt on the support of Ingress bandwidth limiting in OVS, anyone<br></span></div><div><span>that knows if Ingress QoS is supported in OVS we want your feedback :)<br></span></div></div></div></div></span></blockquote></blockquote><div>I do not think so, but don't take my word for granted.</div><div>You can ping somebody in #openvswitch or post to <a href="mailto:ovs-discuss@openvswitch.org">ovs-discuss@openvswitch.org</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px"><span><div><div><div dir="ltr"><div><span></span></div><div><span>(For example implementing OF1.3 Metering spec)<br></span></div><div><span><br>Thanks all (Miguel, Sean or anyone else, please update this if i forgot anything)<br></span></div><div><span><br>[1] <a href="https://wiki.openstack.org/wiki/Meetings/QoS" target="_blank">https://wiki.openstack.org/wiki/Meetings/QoS</a><br>[2] </span><span><a rel="nofollow" href="https://review.openstack.org/#/c/88599/" target="_blank">https://review.openstack.org/#/c/88599/</a><br>[3] <a href="https://review.openstack.org/#/c/136760/" target="_blank">https://review.openstack.org/#/c/136760/</a></span><b><br></b></div></div>
</div><div><div>__________________________________________________________________________</div><div>OpenStack Development Mailing List (not for usage questions)</div><div>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a></div><div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>