Open Stack

Hi Dan:

 

As I said in my previous reply, I'm all for having cohesive API model
across Openstack components, at the same time we should be clear to take
the requirements into consideration and map it to our Netstack use cases
properly and if possible/required enhance it. 

BTW: The comment posted in the Etherpad was made by me prior to the
design summit and still echoes the same point as I said in the previous
line. This was also before we agreed as a team in the summit for plug-in
based model though it was in various proposals.  We didn't spend any
time discussing details - how multiple plug-ins advertise/register and
various other details to start with. Also I'm not sure couple of us
agreeing or disagreeing in the etherpad can be taken as complete team
decision as I'm also new to this process.

 

I also see other emails from Rick C, Dan Prince and Jorge W and there is
already some work happened and Jorge is working towards a formal
approval process.

 

I think we should quickly start with this as basis and review, enhance
it if we see a value in concept like "port profiles" proposed in Ying's
doc for Quantum extensions. I agree we need to discuss, decide on this
as soon as possible and move on to start developing Quantum side
extensions.

 

Ram

 

 

From: Dan Wendlandt [mailto:dan at nicira.com] 
Sent: Saturday, May 21, 2011 1:06 PM
To: Ram Durairaj (radurair)
Cc: Ying Liu (yinliu2); openstack at lists.launchpad.net; Jorge Williams
Subject: Re: [Openstack] [NetStack] Quantum Service API extension
proposal

 

 

On Sat, May 21, 2011 at 11:51 AM, Ram Durairaj (radurair)
<radurair at cisco.com> wrote:

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.

 

Hi Ram,  

 

Apologies if I have misinterpreted the consensus here, but I seem to
remember widespread verbal agreement during the summit on basing the API
and its extensions off of the standard OpenStack mechanisms.  Also, the
main Quantum Diablo Etherpad: http://etherpad.openstack.org/6LJFVsQAL7
(specific text pasted below) seems to show you and Salvatore agreeing to
Erik's comment that we should use the standard OpenStack API and it
includes a link to Jorge's doc on OpenStack Extensions.   

 

Jorge's proposal for extensions includes things like extension
querying/discovery, a mechanism for preventing conflicts between
extension fields from different vendors, etc. that I think are pretty
fundamental to the what we'll need to make Quantum successful.  As a
result, I am personally still strongly in favor of using the standard
OpenStack extension mechanism as the base of our API mechanism for
Quantum.   

 

I think Jorge's work is still in progress (Jorge?) so there should be an
opportunity to provide input on that front as well.  If there are types
of extensions that you are thinking about that won't work in the
standard OpenStack model or if you simply think there is a better way to
do it, that is something we should try to flush out ASAP.   

 

Dan

 

 

=======  Start From Etherpad ======== 

 

4. For EACH network service (could be one or more depending on question
#3), should there be a single, canonical REST API or should there be
multiple APIs?  By canonical, we mean the base API is the same
regardless of the driver/plugin that is implementing it.  How should API
extensibility be handled? 

 

POSSIBLE ANSWERS:

 

EC - [8] We should strive for a single approach across all Open Stack
services.  To that end, we should follow the nova model and have a
single "core" REST API that is applicable across all drivers/service
engines.  Where particular operations, headers, attributes, etc. are
niche or vendor specific, API extensions should be implemented that
allow for those capabilities to be programatically exposed but not
required to be supported by all drivers/service engines.  If you are not
familiar with the concept of OpenStack API extensions, there is a
presentation here -
http://wiki.openstack.org/JorgeWilliams?action=AttachFile&do=get&target=
Extensions.pdf.  Jorge is also doing a talk about this on Tue, 2PM at
the Diablo summit.

 

RamD[8] Completely agree. APIs should be OpenStack API model

 

SO[8]: Agree with Erik and Ram.

 

 =======  End From Etherpad ======== 

 

 

 

 

	 

	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 at lists.launchpad.net
[mailto:openstack-bounces+radurair <mailto:openstack-bounces%2Bradurair>
=cisco.com at lists.launchpad.net] On Behalf Of Dan Wendlandt
	Sent: Saturday, May 21, 2011 11:05 AM
	To: Ying Liu (yinliu2)

	
	Cc: openstack at lists.launchpad.net

	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 at cisco.com> 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 at lists.launchpad.net
	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
	~~~~~~~~~~~~~~~~~~~~~~~~~~~




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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110522/09ded44a/attachment.html>