Open Stack

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 at rackspace.com]
> Sent: Thursday, May 26, 2011 7:48 PM
> To: Ying Liu (yinliu2)
> Cc: Rick Clark; <openstack at 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.com at lists.launchpad.net
> >> [mailto:openstack-bounces+yinliu2=cisco.com at lists.launchpad.net] On
> >> Behalf Of Jorge Williams
> >> Sent: Sunday, May 22, 2011 8:39 AM
> >> To: Rick Clark
> >> Cc: <openstack at 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 <dan at nicira.com> wrote:
> >>>
> >>>> On Sat, May 21, 2011 at 11:51 AM, Ram Durairaj (radurair) <
> >>>> radurair at 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.com at lists.launchpad.net
> >> [mailto:
> >>>>> openstack-bounces+radurair=cisco.com at lists.launchpad.net] *On
> >> Behalf Of *Dan
> >>>>> Wendlandt
> >>>>> *Sent:* Saturday, May 21, 2011 11:05 AM
> >>>>> *To:* Ying Liu (yinliu2)
> >>>>>
> >>>>> *Cc:* openstack at 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)
> >> <yinliu2 at 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 at 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 at lists.launchpad.net
> >>>> Unsubscribe : https://launchpad.net/~openstack
> >>>> More help   : https://help.launchpad.net/ListHelp
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~openstack
> >>> Post to     : openstack at 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 abuse at rackspace.com, and delete the original message.
> >> Your cooperation is appreciated.
> >>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to     : openstack at 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 abuse at rackspace.com, and delete the original message.
> Your cooperation is appreciated.