In the current approach QoS support is being "hardwired" into ML2.
Maybe this is not the best way of doing that, as perhaps it will end up requiring every mech driver which enforces VIF configuration should support it. I see two routes. One is a mechanism driver similar to l2-pop, and then you might have a look at the proposed extension framework (and partecipate into the discussion). The other is doing a service plugin. Still, we'll have to solve how to implement the "binding" between a port/network and the QoS entity. If we go for the approach we've chosen so far the resource extension model you still have to deal with ML2 extensions. But I like orthogonality in services, and QoS is a service to me. Another arguable point is that we might want to reconsider our abuse^H^H^H^H^H use of resource attribute extension, but this is a story for a different thread. Regarding the incubator request, I think we need to wait for the process to be "blessed". But you have my support and I would happy to help to assist with this work item through its process towards graduation. This obviously provided the QoS team wants me to do that! Salvatore On 19 August 2014 23:15, Alan Kavanagh <alan.kavan...@ericsson.com> wrote: > +1, I am hoping this is just a short term holding point and this will > eventually be merged into main branch as this is a feature a lot of > companies, us included would definitely benefit from having supported and > many thanks to Sean for sticking with this and continue to push this. > /Alan > > -----Original Message----- > From: Collins, Sean [mailto:sean_colli...@cable.comcast.com] > Sent: August-19-14 8:33 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: [openstack-dev] [Neutron][QoS] Request to be considered for > neutron-incubator > > Hi, > > The QoS API extension has lived in Gerrit/been in review for about a year. > It's gone through revisions, summit design sessions, and for a little > while, a subteam. > > I would like to request incubation in the upcoming incubator, so that the > code will have a more permanent "home" where we can collaborate and improve. > -- > Sean M. Collins > _______________________________________________ > OpenStack-dev mailing list > OpenStackfirstname.lastname@example.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStackemail@example.com > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev