Re: [openstack-dev] [Neutron] QoS API Extension update
Hi, I'd like to support linuxbridge QoS. I submmited the following BP: https://blueprints.launchpad.net/neutron/+spec/ml2-qos-linuxbridge I won't attend the summit but Toshihiro, my co-worker will attend the summit and attend the QoS session. Thanks. Itsuro Oda On Wed, 16 Oct 2013 17:21:36 + Alan Kavanagh wrote: > Cheers Sean > > I will take a look at the wiki and update accordingly. I took a look at your > BP, its right along the lines of what I feel is also needed and what we are > planning to submit (being finalised as I write this email) though we are also > adding some additional QoS attributes to be supported based on OVS as one > source. I took a look at your API and the BP we are going to submit is very > much inline and complementary to yours hence why I think we can actually > combine them and do a joint pitch on thisat least that’s my thinking on > it! > > Will send BP as soon as its finalised ;-) > > BR > Alan > > -Original Message- > From: Sean M. Collins [mailto:s...@coreitpro.com] > Sent: October-16-13 12:08 PM > To: OpenStack Development Mailing List > Subject: Re: [openstack-dev] [Neutron] QoS API Extension update > > On Wed, Oct 16, 2013 at 03:45:29PM +, Alan Kavanagh wrote: > > Will hopefully submit that really soon. Perhaps we can look at combining > > both of them and discuss this in Hong Kong as I have looked over your BP > > and I can see some benefit in combining them both. > > Hi Alan, > > That sounds great - the objective of my BP was to try and make a QoS API > extension that was flexible enough that everyone could make their own > implementation. At this point, this is accomplished through storing key/value > pairs that are linked back to a QoS object, via the policies attribute (which > maps to the qos_policies table), that stores implementation specific > behavior/configuration. > > There is also a wiki page, that has some useful links: > > https://wiki.openstack.org/wiki/Neutron/QoS > > > -- > Sean M. Collins > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Itsuro ODA ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] QoS API Extension update
Cheers Sean I will take a look at the wiki and update accordingly. I took a look at your BP, its right along the lines of what I feel is also needed and what we are planning to submit (being finalised as I write this email) though we are also adding some additional QoS attributes to be supported based on OVS as one source. I took a look at your API and the BP we are going to submit is very much inline and complementary to yours hence why I think we can actually combine them and do a joint pitch on thisat least that’s my thinking on it! Will send BP as soon as its finalised ;-) BR Alan -Original Message- From: Sean M. Collins [mailto:s...@coreitpro.com] Sent: October-16-13 12:08 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Neutron] QoS API Extension update On Wed, Oct 16, 2013 at 03:45:29PM +, Alan Kavanagh wrote: > Will hopefully submit that really soon. Perhaps we can look at combining both > of them and discuss this in Hong Kong as I have looked over your BP and I can > see some benefit in combining them both. Hi Alan, That sounds great - the objective of my BP was to try and make a QoS API extension that was flexible enough that everyone could make their own implementation. At this point, this is accomplished through storing key/value pairs that are linked back to a QoS object, via the policies attribute (which maps to the qos_policies table), that stores implementation specific behavior/configuration. There is also a wiki page, that has some useful links: https://wiki.openstack.org/wiki/Neutron/QoS -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] QoS API Extension update
On Wed, Oct 16, 2013 at 03:45:29PM +, Alan Kavanagh wrote: > Will hopefully submit that really soon. Perhaps we can look at combining both > of them and discuss this in Hong Kong as I have looked over your BP and I can > see some benefit in combining them both. Hi Alan, That sounds great - the objective of my BP was to try and make a QoS API extension that was flexible enough that everyone could make their own implementation. At this point, this is accomplished through storing key/value pairs that are linked back to a QoS object, via the policies attribute (which maps to the qos_policies table), that stores implementation specific behavior/configuration. There is also a wiki page, that has some useful links: https://wiki.openstack.org/wiki/Neutron/QoS -- Sean M. Collins pgpFaQTxkBTIG.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] QoS API Extension update
On Oct 16, 2013, at 9:54 AM, Sean M. Collins wrote: > Hello, > > Just a quick update on the QoS API Extension - I plan on attending the > summit in Hong Kong and have registered a summit proposal to discuss the > current work that has been done. > > Currently I have two reviews under way: > > API Extension & Database models: > > https://review.openstack.org/#/c/28313/ > > Agent & OVS implementation: > > https://review.openstack.org/#/c/45232/ > > Our current environment uses provider networking & VLANs, so I've been > targeting the work to what we currently are deploying inside of Comcast, > so the work on the OVS agent is a bit narrow - I haven't done any work > on the GRE side. > > Both are currently WIP - I need better test coverage in places, handle > some edge cases (Agent restarts for example) and code quality > improvements. > > If people would be so kind as to look over the Agent & OVS > implementation and give me some feedback, I would really appreciate it. > > I plan to study up on the ML2 plugin and add support for the QoS > extension, so we can transition away from the OVS plugin when it is > deprecated. Thanks for sending this out Sean, this looks good and I'll eyeball it closer over the next week. I put a note on your Summit session to possibly combine it into one of the ML2 "Super Sessions" since it makes sense to implement this in the ML2 plugin at first. We'll need to consider how this works with the LinuxBridge agent as well so the API works across both that and the OVS agent. Thanks! Kyle ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] QoS API Extension update
Hi Sean Just an FYI, we are also planning a QoS API Extension Blueprint for the Icehouse Design Summit. Will hopefully submit that really soon. Perhaps we can look at combining both of them and discuss this in Hong Kong as I have looked over your BP and I can see some benefit in combining them both. BR Alan -Original Message- From: Sean M. Collins [mailto:s...@coreitpro.com] Sent: October-16-13 10:55 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] QoS API Extension update Hello, Just a quick update on the QoS API Extension - I plan on attending the summit in Hong Kong and have registered a summit proposal to discuss the current work that has been done. Currently I have two reviews under way: API Extension & Database models: https://review.openstack.org/#/c/28313/ Agent & OVS implementation: https://review.openstack.org/#/c/45232/ Our current environment uses provider networking & VLANs, so I've been targeting the work to what we currently are deploying inside of Comcast, so the work on the OVS agent is a bit narrow - I haven't done any work on the GRE side. Both are currently WIP - I need better test coverage in places, handle some edge cases (Agent restarts for example) and code quality improvements. If people would be so kind as to look over the Agent & OVS implementation and give me some feedback, I would really appreciate it. I plan to study up on the ML2 plugin and add support for the QoS extension, so we can transition away from the OVS plugin when it is deprecated. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
