Open Stack

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