openstack team mailing list archive

["Ying Liu (yinliu2)" <yinliu2@xxxxxxxxx>]

One more thing we can discuss in today's meeting:

 

What are standard attributes associated with Resources in Core API? 

 

In Alex's revision of core API spec
http://wiki.openstack.org/QuantumAPIBase?action=AttachFile&do=get&target
=Quantum_API_spec-draft-v0.11+-+Alex.docx

, he proposed some. For example, network has "id", "name",
"datacreated", "numberAttachedPorts" and etc. Based on that, I further
extend and create a simple data model to describe Network, Port and
attachment resources. Details can be found at
http://wiki.openstack.org/QuantumAPIExtensions?action=AttachFile&do=view
&target=quantum_api_extension.pdf  (These are some initial thoughts.
Open for community' discussion. E.g. the extensible construct can be
removed from the attribute list or make it as fixed construct.)

 

I think it's important to clarify these attributes in core API before
talking about extensions.

 

Best,

Ying

 

 

 

From: Ram Durairaj (radurair) 
Sent: Tuesday, May 24, 2011 9:53 AM
To: Dan Wendlandt; Ying Liu (yinliu2)
Cc: openstack@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Openstack] [NetStack] Quantum Service API extension
proposal

 

Glad to see we are  converging.

 

Couple of things/questions that we need to discuss/decide in our meeting
today.

 

1.       For plugin-specific extensions - Option 1: Use DataExtension
scheme as in Jorge proposal with Key-Value pairs.

Any other options? Or just go with. BTW, I agree with this model.

2.       Port Profile construct - To have it as part of "Core API" or we
don't need it now have, if any plugin wants it have it as a extension?

a.       I see a great value in having the port profile as a "core API"
construct. Please refer to Ying's previous email.

3.       If I understand correctly,  I also see a valid point in Alex's
proposal - Use key-value pairs for Core API for standard capability, as
well.

a.       Do we go with this or not?

 

Ram

 

 

From: openstack-bounces+radurair=cisco.com@xxxxxxxxxxxxxxxxxxx
[mailto:openstack-bounces+radurair=cisco.com@xxxxxxxxxxxxxxxxxxx] On
Behalf Of Dan Wendlandt
Sent: Monday, May 23, 2011 10:33 PM
To: Ying Liu (yinliu2)
Cc: openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] [NetStack] Quantum Service API extension
proposal

 

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-exten
sions

 

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@xxxxxxxxx>
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@xxxxxxxxxx] 
Sent: Monday, May 23, 2011 4:54 PM
To: Alex Neefus
Cc: Ying Liu (yinliu2); openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] [NetStack] Quantum Service API extension
proposal

 

 

 

 

On Mon, May 23, 2011 at 1:05 PM, Alex Neefus <alex@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
[mailto:openstack-bounces+alex <mailto:openstack-bounces%2Balex>
=mellanox.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Ying Liu (yinliu2)
	Sent: Saturday, May 21, 2011 1:10 PM
	To: openstack@xxxxxxxxxxxxxxxxxxx
	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@xxxxxxxxxxxxxxxxxxx
	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
~~~~~~~~~~~~~~~~~~~~~~~~~~~