Re: [Openstack] [Netstack] Quantum Diablo-4 Milestone Release
Congrats all Lets push forward towards Diablo release Cheers Ram Sent from my iPhone On Aug 26, 2011, at 15:44, Dan Wendlandt d...@nicira.com wrote: Hello folks, The Quantum Diablo-4 Milestone has been released. Download details are at: https://launchpad.net/quantum/diablo/diablo-4 Major new features completed during this milestone included: - API extensions framework - Cisco plugin + associated extensions - v1.0 release of API We also made significant steps toward getting Quantum integrated with both Nova and the OpenStack Dashboard project, though more work remains with respect to Nova/Quantum integration. Congrats to the Quantum team! Dan -- Mailing list: https://launchpad.net/~netstack Post to : netst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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@lists.launchpad.net
[mailto:openstack-bounces+radurair=cisco@lists.launchpad.net] On
Behalf Of Dan Wendlandt
Sent: Monday, May 23, 2011 10:33 PM
To: Ying Liu (yinliu2)
Cc: openstack@lists.launchpad.net
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) yinl...@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-2011.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:d...@nicira.com]
Sent: Monday, May 23, 2011 4:54 PM
To: Alex Neefus
Cc: Ying Liu (yinliu2); openstack@lists.launchpad.net
Subject: Re: [Openstack] [NetStack] Quantum Service API extension
proposal
On Mon, May 23, 2011 at 1:05 PM, Alex Neefus a...@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
Re: [Openstack] [NetStack] Quantum Service API extension proposal
Hi Dan: As I said in my previous reply, I'm all for having cohesive API model across Openstack components, at the same time we should be clear to take the requirements into consideration and map it to our Netstack use cases properly and if possible/required enhance it. BTW: The comment posted in the Etherpad was made by me prior to the design summit and still echoes the same point as I said in the previous line. This was also before we agreed as a team in the summit for plug-in based model though it was in various proposals. We didn't spend any time discussing details - how multiple plug-ins advertise/register and various other details to start with. Also I'm not sure couple of us agreeing or disagreeing in the etherpad can be taken as complete team decision as I'm also new to this process. I also see other emails from Rick C, Dan Prince and Jorge W and there is already some work happened and Jorge is working towards a formal approval process. I think we should quickly start with this as basis and review, enhance it if we see a value in concept like port profiles proposed in Ying's doc for Quantum extensions. I agree we need to discuss, decide on this as soon as possible and move on to start developing Quantum side extensions. Ram From: Dan Wendlandt [mailto:d...@nicira.com] Sent: Saturday, May 21, 2011 1:06 PM To: Ram Durairaj (radurair) Cc: Ying Liu (yinliu2); openstack@lists.launchpad.net; Jorge Williams Subject: Re: [Openstack] [NetStack] Quantum Service API extension proposal On Sat, May 21, 2011 at 11:51 AM, Ram Durairaj (radurair) radur...@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=AttachFiledo=gettarget= 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
Re: [Openstack] [NetStack] Quantum Service API extension proposal
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. 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@lists.launchpad.net [mailto:openstack-bounces+radurair=cisco@lists.launchpad.net] On Behalf Of Dan Wendlandt Sent: Saturday, May 21, 2011 11:05 AM To: Ying Liu (yinliu2) Cc: openstack@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-exten sions . 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) yinl...@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=AttachFiledo=view target=quantum_api_extension.pdf or http://wiki.openstack.org/QuantumAPIExtensions?action=AttachFiledo=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@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 ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Network service: Quantum and Donabe BPs
Hello All: As per our discussions in Design summit, created 4 Blueprint (BP) placeholder for Donabe...and also see 6 BPs for Quantum ...wondering about need for so many # of BPs... Could we just have two BPs one for Quantum and another for Donabe? That way most of the discussions and the subsequent dev may be all inter related wrt one of these BP... Sorry, new to this BP/Launchpad process...So not clear on why / how to breakdown into Multiple BPs...I see a benefit if its all self contained. Thoughts? Ram ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Project Donabe: Call for participation.
Hello All: Please join us at Camino Real Room (2nd floor) tomorrow from 1-2, if you are interested in participating in Project Donabe (Container Service) code development efforts. We can start discussing about APIs and all the good stuff. Thanks Ram ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
