<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: #A0A0A8;">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 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><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><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><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><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><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><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">https://wiki.openstack.org/wiki/Meetings/QoS</a><br>[2] </span><span><a rel="nofollow" href="https://review.openstack.org/#/c/88599/">https://review.openstack.org/#/c/88599/</a><br>[3] <a href="https://review.openstack.org/#/c/136760/">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">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a></div><div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>