Open Stack

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&target=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=view&target=quantum_api_extension.pdf
>>> 
>>> or
>>> 
>>> 
>>> http://wiki.openstack.org/QuantumAPIExtensions?action=AttachFile&do=view&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.