openstack team mailing list archive

["Ram Durairaj (radurair)" <radurair@xxxxxxxxx>]

Hi Dan:

 

As far as I remember, In Design summit, we've agreed to expose "extra"
attributes for Virtual networks and any other vendor specific features
using "API-Extensions" and possibly thru existing Openstack extension
mechanisms. Don't recall that we've concluded on Jorge's proposal. 

 

Also I think it's better to follow a consistent model across the
Openstack , provided the current Jorge's proposal is generic enough and
flexible enough for what we are trying to do in our NetStack side. I
think we should take a look at Jorge's and Ying model and as a team we
decide.

 

As I informed our Netstack team during our Design Summit, absolutely. we
can take up the API extensions and Sure, Ying can lead and help develop
the workstream and the related code contributions as part of overall
Quantum. I'll let Ying add more here .


Thanks


Ram

 

 

From: openstack-bounces+radurair=cisco.com@xxxxxxxxxxxxxxxxxxx
[mailto:openstack-bounces+radurair=cisco.com@xxxxxxxxxxxxxxxxxxx] On
Behalf Of Dan Wendlandt
Sent: Saturday, May 21, 2011 11:05 AM
To: Ying Liu (yinliu2)
Cc: openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] [NetStack] Quantum Service API extension
proposal

 

Hi Ying,

 

Thanks for sending this out.  I think many of the capabilities you are
looking to introduce (ability to configure ACLs, QoS, packet statistics)
are definitely things we will want Quantum to expose as API extensions
(and possibly in the future, as part of the base API if they are
sufficiently general). 

 

During the summit we had agreed that extensions to Quantum would follow
the "standard" openstack extension mechanisms proposed by Jorge
Williams, see:
http://www.slideshare.net/RackerWilliams/openstack-extensions

 

I've been trying to find someone to take a lead on building the API
extension framework within quantum to provide plugins with the ability
to register such extensions in a way compatible with Jorge's proposal,
so perhaps you would like to take the lead on designing and coding that?
The blueprint is at:
https://blueprints.launchpad.net/network-service/+spec/quantum-api-exten
sions .  Out plan from the summit was that all functionality except the
base "network connectivity" would initially be exposed as extensions,
with the ability for these extensions to be proposed as additions to the
base API in the future.  Thanks, 

 

 

Dan

 

On Sat, May 21, 2011 at 10:09 AM, Ying Liu (yinliu2) <yinliu2@xxxxxxxxx>
wrote:

Hi all,

 

We just posted a proposal for OpenStack Quantum Service API extension on
community wiki page at
http://wiki.openstack.org/QuantumAPIExtensions?action=AttachFile&do=view
&target=quantum_api_extension.pdf

or 

http://wiki.openstack.org/QuantumAPIExtensions?action=AttachFile&do=view
&target=quantum_api_extension.docx

 

Please review and let us know your comments/suggestions. An etherpad
page is created for API extension discussion
http://etherpad.openstack.org/uWXwqQNU4s

 

Best,

Ying


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp




-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt 
Nicira Networks, Inc. 
www.nicira.com | www.openvswitch.org
Sr. Product Manager 
cell: 650-906-2650
~~~~~~~~~~~~~~~~~~~~~~~~~~~