Hi Jorge, Thanks for the clarification. This is quite aligned with what we thought about extensions.
Best, Ying > -----Original Message----- > From: Jorge Williams [mailto:jorge.willi...@rackspace.com] > Sent: Tuesday, June 14, 2011 11:06 AM > To: Ying Liu (yinliu2) > Cc: <openstack@lists.launchpad.net> > Subject: Re: [Openstack] [NetStack] Quantum Service API extension > proposal > > 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
