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 <d...@nicira.com> wrote: >On Sat, May 21, 2011 at 11:51 AM, Ram Durairaj (radurair) < >radur...@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....@lists.launchpad.net [mailto: >> openstack-bounces+radurair=cisco....@lists.launchpad.net] *On Behalf Of *Dan >> Wendlandt >> *Sent:* Saturday, May 21, 2011 11:05 AM >> *To:* Ying Liu (yinliu2) >> >> *Cc:* openstack@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-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) <yinl...@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@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 >~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >_______________________________________________ >Mailing list: https://launchpad.net/~openstack >Post to : openstack@lists.launchpad.net >Unsubscribe : https://launchpad.net/~openstack >More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
