Open Stack

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.williams at rackspace.com]
> Sent: Tuesday, June 14, 2011 11:06 AM
> To: Ying Liu (yinliu2)
> Cc: <openstack at 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.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.
> >
> 
> This email may include confidential information. If you received it in
> error, please delete it.