openstack team mailing list archive

[Rick Clark <rick@xxxxxxxxxxxxx>]

It is my understanding that we would use the standard Openstack extension mechanism,  though I don't believe jorge's proposal has been officially accepted yet.  
However our plugin model will require a complex way of expressing capability that might not be a part of jorge's proposal.  

T-Mobile. America’s First Nationwide 4G Network

Dan Wendlandt <dan@xxxxxxxxxx> wrote:

>On Sat, May 21, 2011 at 11:51 AM, Ram Durairaj (radurair) <
>radurair@xxxxxxxxx> 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@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-extensions.  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
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>
>
>
>-- 
>~~~~~~~~~~~~~~~~~~~~~~~~~~~
>Dan Wendlandt
>Nicira Networks, Inc.
>www.nicira.com | www.openvswitch.org
>Sr. Product Manager
>cell: 650-906-2650
>~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>_______________________________________________
>Mailing list: https://launchpad.net/~openstack
>Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp