openstack team mailing list archive

[Jorge Williams <jorge.williams@xxxxxxxxxxxxx>]

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.williams@xxxxxxxxxxxxx]
>> Sent: Thursday, May 26, 2011 7:48 PM
>> To: Ying Liu (yinliu2)
>> Cc: Rick Clark; <openstack@xxxxxxxxxxxxxxxxxxx>
>> 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.com@xxxxxxxxxxxxxxxxxxx
>>>> [mailto:openstack-bounces+yinliu2=cisco.com@xxxxxxxxxxxxxxxxxxx] On
>>>> Behalf Of Jorge Williams
>>>> Sent: Sunday, May 22, 2011 8:39 AM
>>>> To: Rick Clark
>>>> Cc: <openstack@xxxxxxxxxxxxxxxxxxx>
>>>> 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 <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=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@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
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~openstack
>>>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>>>> 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 abuse@xxxxxxxxxxxxx, and delete the original message.
>>>> Your cooperation is appreciated.
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>>> 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 abuse@xxxxxxxxxxxxx, and delete the original message.
>> Your cooperation is appreciated.
> 

This email may include confidential information. If you received it in error, please delete it.