Hi Ying, Yes extensions that belong to one service will be grouped together. So quantum.foo.com/v1.0/extensions is fine.
No, they don't need to be independent services -- I'm expecting that the query to see what extensions are available should be an open all --- but at the end of the day I suppose that whether or not it is depends on the operator. Extensions just add functionality to the API, authentication should work as it normally does. -jOrGe W. On May 31, 2011, at 3:52 PM, Ying Liu (yinliu2) wrote: > Hi Jorge, > > Thanks. > From what you described, should we say that all the extensions belonging > to one service will be grouped together? > For example, <quantum.foo.com/v1.0/extensions> query will list all the > extensions under the quantum service. > > Then what's the relationship between core and the extension? Are they > independent web services? How will they share the authentication part > (assuming the core API part has handled the authentication)? > > Best, > Ying > >> -----Original Message----- >> From: Jorge Williams [mailto:jorge.willi...@rackspace.com] >> Sent: Thursday, May 26, 2011 7:48 PM >> To: Ying Liu (yinliu2) >> Cc: Rick Clark; <openstack@lists.launchpad.net> >> Subject: Re: [Openstack] [NetStack] Quantum Service API extension >> proposal >> >> Hi Ying, >> >> The query should look something like this: >> >> Openstack.foo.com/path/to/quantum/v1.0/extensions >> >> In most cases it may look like this >> >> quantum.foo.com/v1.0/extensions >> >> It's important to note that extensions are always interpreted in >> relation to a particular version of a core API. That's because, >> something that is an extension in v1.0 may be a core feature in v2.0. >> Thus, /v1.0/extensions and /v2.0/extensions may return a different set >> of extensions. >> >> As for additional pointers, I'm in the process of drafting a guide to >> extensions. Since there is so much interest, I'll start publishing as >> I write it -- expect the first couple of chapters soon. >> >> -jOrGe W. >> >> On May 26, 2011, at 6:44 PM, Ying Liu (yinliu2) wrote: >> >>> Hi Jorge, >>> >>> A quick question about the extension mechanisms you described at the >>> summit. >>> On page 19, the extension is queryable via /extensions. Could you >> give >>> an example of full URI for this query service? >>> Is it something like: >>> Openstack.foo.com/openstack/network/extensions >>> Or >>> Openstack.foo.com/openstack/extensions >>> Or >>> Openstack.foo.com/opentstack/network/quantum_service/extensions >>> >>> For the extension work with LB v1.1, if there is any related >>> information, could you send me a pointer? >>> >>> Best, >>> Ying >>> >>> >>>> -----Original Message----- >>>> From: openstack-bounces+yinliu2=cisco....@lists.launchpad.net >>>> [mailto:openstack-bounces+yinliu2=cisco....@lists.launchpad.net] On >>>> Behalf Of Jorge Williams >>>> Sent: Sunday, May 22, 2011 8:39 AM >>>> To: Rick Clark >>>> Cc: <openstack@lists.launchpad.net> >>>> Subject: Re: [Openstack] [NetStack] Quantum Service API extension >>>> proposal >>>> >>>> Hi Rick, >>>> >>>> I'm in the process of putting together a formal proposal to >> OpenStack >>>> governance on extensions. I'll be submitting it for review very > soon. >>>> >>>> Our goal is provide a system that is flexible and generic enough to >>> add >>>> extendability to any OpenStack API in a consistent manner. Of >> course >>>> we will need your input (and that of the community as a whole) to >> make >>>> sure that we can achieve this. >>>> >>>> To that end, I'd love to understand your use case a bit better. Is >>>> there anything missing from the extension mechanism as I described >> it >>>> at the summit? >>>> >>>> (Slides >>>> >>> >> > http://wiki.openstack.org/JorgeWilliams?action=AttachFile&do=view&targe >>>> t=Extensions.pdf) >>>> >>>> I should also note that you need not use the extension mechanism to >>>> express capabilities in the API. It's okay and even desirable for >> an >>>> API to express capabilities in a manner that makes sense for that >>>> particular service. >>>> >>>> For example, I'm working with the load balancer team on 1.1 of the >> LB >>>> API. Load Balancers may support many different algorithms (round >>> robin, >>>> random, etc.). The approach we took there is to have the core API >>>> define a reasonable set of common algorithms and have an endpoint >>> where >>>> you can query what algorithms are available in a particular >>> deployment. >>>> Extensions don't come into play unless an implementation offers >>> support >>>> for an algorithm that's not in the common set. It's only in this >> case >>>> where we need to take care of conflicts between vendors and so on. >>>> >>>> -jOrGe W. >>>> >>>> On May 21, 2011, at 4:21 PM, Rick Clark wrote: >>>> >>>>> 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=vie >>>> w&target=quantum_api_extension.pdf >>>>>>> >>>>>>> or >>>>>>> >>>>>>> >>>>>>> >>>> >>> >> > http://wiki.openstack.org/QuantumAPIExtensions?action=AttachFile&do=vie >>>> w&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 >>>> >>>> >>>> >>>> Confidentiality Notice: This e-mail message (including any attached >> or >>>> embedded documents) is intended for the exclusive and confidential >> use >>>> of the >>>> individual or entity to which this message is addressed, and unless >>>> otherwise >>>> expressly indicated, is confidential and privileged information of >>>> Rackspace. >>>> Any dissemination, distribution or copying of the enclosed material >> is >>>> prohibited. >>>> If you receive this transmission in error, please notify us >>> immediately >>>> by e-mail >>>> at ab...@rackspace.com, and delete the original message. >>>> Your cooperation is appreciated. >>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~openstack >>>> Post to : openstack@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~openstack >>>> More help : https://help.launchpad.net/ListHelp >> >> >> >> Confidentiality Notice: This e-mail message (including any attached or >> embedded documents) is intended for the exclusive and confidential use >> of the >> individual or entity to which this message is addressed, and unless >> otherwise >> expressly indicated, is confidential and privileged information of >> Rackspace. >> Any dissemination, distribution or copying of the enclosed material is >> prohibited. >> If you receive this transmission in error, please notify us > immediately >> by e-mail >> at ab...@rackspace.com, and delete the original message. >> Your cooperation is appreciated. > This email may include confidential information. If you received it in error, please delete it. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
