<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 7 April 2015 at 00:33, Armando M. <span dir="ltr"><<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On 6 April 2015 at 08:56, 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>
                    <span style="font-size:14px">I’d like to co-organized a QoS weekly meeting with Sean M. Collins,</span></div><div><span style="font-size:14px"><br></span></div><div><span style="font-size:14px">    In the last few years, the interest for QoS support has increased, Sean has been leading</span></div><div><span style="font-size:14px">this effort [1] and we believe we should get into a consensus about how to model an extension</span></div><div><span style="font-size:14px">to let vendor plugins implement QoS capabilities on network ports and tenant networks, and</span></div><div><span style="font-size:14px">how to extend agents, and the reference implementation & others [2]</span></div></blockquote></span></div></div></div></blockquote><div><br></div><div>As you surely know, so far every attempt to achieve a consensus has failed in a pretty miserable way.</div><div>This mostly because "QoS" can be interpreted in a lot of different ways, both from the conceptual and practical perspective.</div><div>It is important in my opinion to clearly define the goals first. For instance a simple extensions for bandwidth limiting could be a reasonable target for the Liberty release.</div><div>Moving things such as ECN into "future works" is the right thing to do in my opinion. Attempting to define a flexible framework that can deal with advanced QoS policies specification is a laudable effort, but I am a bit skeptical about its feasibility.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><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:14px"><br></span></div><div><span style="font-size:14px">    As per discussion we’ve had during the last few months [3], I believe we should start simple, but</span></div><div><span style="font-size:14px">prepare a model allowing future extendibility, </span><span style="font-size:14px">to allow for example specific traffic rules (per port,</span></div><div><span style="font-size:14px">per IP, etc..), congestion notification support [4], </span><span style="font-size:14px">…</span></div></blockquote></span></div></div></div></blockquote><div><br></div><div>"Simple" in my mind is even more extreme then what you're proposing here... I'd start with bare APIs for specifying bandwidth limiting, and then phase them out once this "framework" is in place.</div><div>Also note that this kind of design bears some overlap with the flavor framework which is probably going to be another goal for Liberty.</div><div><br></div><div>Morever, consider using "common" tools such as the specs repo to share and discuss design documents.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><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><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:14px"></span></div><div><span style="font-size:14px">    It’s the first time I’m trying to organize an openstack/neutron meeting, so, I don’t know what’s the</span></div><div><span style="font-size:14px">best way to do it, or find the best timeslot. I guess interested people may have a saying, so I’ve </span></div><div><span style="font-size:14px">looped anybody I know is interested in the CC of this mail. </span></div></blockquote><div><br></div></span><div>I think that's a good idea. Incidentally I was speaking with Sean regarding Summit session [1], and we were hoping we could get some folks together either prior or during the summit, to try and get some momentum going behind this initiative, once again.</div></div></div></div></blockquote><div><br></div><div>I think is a good idea as well.  I was thinking that perhaps it might be a good idea to grab a design summit session as well (surely not a fishbowl one as they're totally unfit for this purpose).</div><div>However, it might be good to achieve some sort of consensus before the summit, as as we know fairly well now the summit is probably the worst place where consensus can be achieved!</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>We'd need to fill in page [2], and find an empty slot on [3]</div><div><br></div><div>Thanks for starting this thread!</div><div><br></div><div>[1] <a href="https://openstacksummitmay2015vancouver.sched.org/event/27eeef71d5f57997ac09b4c7783c72fe#.VSMIzJT-NhM" target="_blank">https://openstacksummitmay2015vancouver.sched.org/event/27eeef71d5f57997ac09b4c7783c72fe#.VSMIzJT-NhM</a> </div><div>[2] <a href="https://wiki.openstack.org/wiki/NeutronSubTeams" target="_blank">https://wiki.openstack.org/wiki/NeutronSubTeams</a></div><div>[3] <a href="https://wiki.openstack.org/wiki/Meetings" target="_blank">https://wiki.openstack.org/wiki/Meetings</a></div><div><br></div><div><br></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"><span class=""><div><br></div><div><span style="font-size:14px"><br></span></div><div><div><span style="font-size:10pt">Miguel Ángel Ajo</span></div><div><br></div><div><span style="font-size:14px">[1] </span><a href="https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api" target="_blank">https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api</a></div><div><span style="font-size:14px">[2] </span><a href="https://drive.google.com/file/d/0B2XATqL7DxHFRHNjU3k1UFNYRjQ/view?usp=sharing" target="_blank">https://drive.google.com/file/d/0B2XATqL7DxHFRHNjU3k1UFNYRjQ/view?usp=sharing</a></div><div><span style="font-size:14px">[3] </span><a href="https://docs.google.com/document/d/1xUx0Oq-txz_qVA2eYE1kIAJlwxGCSqXHgQEEGylwlZE/edit#heading=h.2pdgqfl3a231" target="_blank">https://docs.google.com/document/d/1xUx0Oq-txz_qVA2eYE1kIAJlwxGCSqXHgQEEGylwlZE/edit#heading=h.2pdgqfl3a231</a></div><div><span style="font-size:14px">[4] </span><a href="https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification" target="_blank">https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification</a></div></div>
            <br></span>__________________________________________________________________________<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>
<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>