Re: [openstack-dev] [Neutron] QoS API Extension update

2013-10-16 Thread Alan Kavanagh
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


Re: [openstack-dev] [Neutron] QoS API Extension update

2013-10-16 Thread Sean M. Collins
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

2013-10-16 Thread Alan Kavanagh
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

2013-10-16 Thread Itsuro ODA
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 alan.kavan...@ericsson.com 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 o...@valinux.co.jp


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev