Open Stack

Hi Ying,

Thanks for the detailed example.  You are correct, this is inline with what
I was thinking.

A "data extension" mechanism like this would let any interested party
cleanly expose additional properties for API port objects, and as Alex
mentioned, potentially for API network objects as well.  From an internal
Quantum architecture perspective, we'll have to discuss how this data gets
passed to the plugin, what validation happens at the API layer, as well as
how plugins are able go beyond basic data extension to add new API methods
and objects.  This is what I'd like to tackle with the blueprint:
https://blueprints.launchpad.net/network-service/+spec/quantum-api-extensions

During the meeting tomorrow we can see if people are largely on the same
page, in which case we can move on to the blueprint on this.

Dan


On Mon, May 23, 2011 at 7:48 PM, Ying Liu (yinliu2) <yinliu2 at cisco.com>wrote:

> Hi Dan,
>
>
>
> Totally agree. “Data Extensions” is the way we can extend the <key, value>
> list for non-base keys.
>
> Actually, we can use this mechanism to extend the extensible <key, value>
> construct proposed earlier, assuming that data construct is already in the
> name space.
>
>
>
> The extension can be something like this (pdf and wadl files defines
> extension content):
>
>
>
> <extension name="Port Configuration Extension"
>
>                namespace="
> http://docs.rackspacecloud.com/network/api/ext/conf/v1.0"
>
> alias="CSCO-CONF"
>
> <
>
>         <atom:link rel="describedby" type="application/pdf"
>
>                    href="
> http://docs.ciscocloud.com/network/api/ext/net-conf-20111111.pdf"/>
>
>         <atom:link rel="describedby" type="application/vnd.sun.wadl+xml"
>
>                    href="
> http://docs.ciscocloud.com/network/api/ext/net-conf.wadl"/>
>
>         <description>
>
>             Adds the configurations to the port.
>
>         </description>
>
>    </extension>
>
>
>
> The data extension:
>
>
>
> {
>
>     "port" : {
>
>         "id" : 8,
>
>         "name" : "My L2 Network",
>
>         "created_at" : "2011-05-18 18:30:40",
>
>         "status" : "Active",
>
>         "configureations" : {
>
>                "*COSO-CONF:acl*" : "permit ip any 209.165.201.2
> 255.255.255.255",
>
>                "vlan_segment" : "5"
>
>                }
>
> }
>
>
>
> Thus, the registration, discovery and promotion mechanism can all follow
> the standard extension mechanism.  Just my understanding, please correct me
> if I missed something here.
>
>
>
> Best,
>
> Ying
>
>
>
> *From:* Dan Wendlandt [mailto:dan at nicira.com]
> *Sent:* Monday, May 23, 2011 4:54 PM
> *To:* Alex Neefus
> *Cc:* Ying Liu (yinliu2); openstack at lists.launchpad.net
> *Subject:* Re: [Openstack] [NetStack] Quantum Service API extension
> proposal
>
>
>
>
>
>
>
>
>
> On Mon, May 23, 2011 at 1:05 PM, Alex Neefus <alex at mellanox.com> wrote:
>
> Hi All –
>
>
>
> I wanted to lend support to this proposal, however I don’t think we should
> be so quick to say this whole thing is an extension.
>
>
>
> Hi Alex, all,
>
>
>
> I'd like to try and level-set here for a minute, as I don't believe people
> are saying that such a mechanism itself would be an extension, but rather
> that it would be a mechanism for plugins to expose extensions.
>
>
>
> Here is the situation as I understand it:  I believe most people would feel
> that having a conf/cap/profile attribute on ports and networks in the core
> API is (at least) one reasonable way of letting plugins exposing additional
> data via the Quantum API.  Where the issue of OpenStack extensions would
> come in is providing a mechanism to introduce new key-value pairs to
> something like the conf/cap/profile attribute.  I'm not expert on API
> extensibility, but doing so seems to be a direct application of the "Data
> Extensions" portion of the OpenStack extensions proposal (see slide 29 of
> http://www.slideshare.net/RackerWilliams/openstack-extensions)
>
>
>
> The OpenStack extensions proposal focuses on standardizing several key
> questions around introducing new data, such as these key-value pairs:
>
> - How do you prevent naming conflicts between keys?
>
> - How does someone easily determine whether a Quantum instance supports a
> certain type of functionality (i.e., a certain key)?
>
> - How does one get access to documentation on the format + type of the
> "value" portion of the key-value pair? (values may be nested objects in
> complex scenarios).
>
> - How do we handle the official "promotion" of a key-value pair from an
> extension to being part of the "base"?
>
>
>
> In my opinion these all seem like good things to standardize across
> OpenStack services and hence be part of Quantum.
>
>
>
> My original response was motivated by the fact that the proposal didn't
> seem to mention using the OpenStack extension mechanism to expose non "base"
> key-value pairs in the conf/cap/profile attribute.  Based on Rick's response
> it seems like the plan is in fact to try and use OpenStack extensions, so
> I'm hoping we're largely on the same page, fingers crossed :)
>
>
>
> Dan
>
>
>
>
>
>
>
>
>
> We benefit a lot from having a standard capabilities mechanism as part of
> our core Quantum API. I like Ying’s key value method as well. I think it’s
> logical, clean and scalable. I propose that basic read access of “cap” off
> of our major objects: network, port, interface be included in our first
> release.
>
>
>
> So in summary I would like to encourage us to add:
>
> GET  /networks/{net_id}/conf
>
> GET  /networks/{net_id}/ports/{port_id}/conf/
>
> GET  {entity}/VIF/conf/
>
>
>
> Each of these would return a list of keys.
>
>
>
> Additionally Quantum base should support
>
> GET  /networks/{net_id}/conf/{key}
>
> GET  /networks/{net_id}/ports/{port_id}/conf/{key}
>
> GET  {entity}/VIF/conf/{key}
>
>
>
> Where {key} is the name of either a standard capability or an extention
> capability. We can define an error code now to designate a capability not
> supported by the plugin. (i.e. 472 – CapNotSupported)
>
>
>
> Finally we don’t need to standardize on every capability that might be
> supported if we provide this simple mechanism. Specific capabilities
> Key,Value sets can be added later but or included as vendor specific
> extensions.
>
>
>
> I’m happy to add this to the wiki if there is consensus. Rick/Dan – Maybe
> this should be a topic for Tuesdays meeting.
>
>
>
> Alex
>
>
>
> ---
>
> Alex Neefus
>
> Senior System Engineer | Mellanox Technologies
>
> (o) 617.337.3116 | (m) 201.208.5771 | (f) 617.337.3019
>
>
>
>
>
>
>
>
>
>
>
> *From:* openstack-bounces+alex=mellanox.com at lists.launchpad.net [mailto:
> openstack-bounces+alex=mellanox.com at lists.launchpad.net] *On Behalf Of *Ying
> Liu (yinliu2)
> *Sent:* Saturday, May 21, 2011 1:10 PM
> *To:* openstack at lists.launchpad.net
> *Subject:* [Openstack] [NetStack] Quantum Service API extension proposal
>
>
>
> 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110523/d63d1418/attachment.html>