[Netstack] Discussion on Authentication/Authorization for Quantum

BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft Exchange Server 2007 VERSION:2.0 BEGIN:VTIMEZONE TZID:GMT Standard Time BEGIN:STANDARD DTSTART:16010101T02 TZOFFSETFROM:+0100 TZOFFSETTO:+ RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10 END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T01 T

[Netstack] Discussion on Authentication/Authorization for Quantum

BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft Exchange Server 2007 VERSION:2.0 BEGIN:VTIMEZONE TZID:GMT Standard Time BEGIN:STANDARD DTSTART:16010101T02 TZOFFSETFROM:+0100 TZOFFSETTO:+ RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10 END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T01 T

[Netstack] [Quantum] Splitting unit tests and functional tests

Hi all, As agreed during our last meeting, the branches for unit tests and functional test have been split. Unit tests: Blueprint: https://blueprints.launchpad.net/quantum/+spec/api-spec-unit-tests Code: https://code.launchpad.net/~netstack/quantum/quantum-unit-tests (lp:~netstack/quantum/quant

Re: [Netstack] Quantum API Client Library Status

Hi Tyler, It would be good to have your client library code for the functional tests work as well. I think you have done a great work; in particular I love the api_call decorator, it really makes the code much more readable and maintainable. Are you considering some unit tests for this clien

[Netstack] Discussion on AuthN/AuthZ for Quantum

Hi all, As you might already know, today (July 14th) we had a meeting over the phone aimed at discussing authentication and authorization for Quantum. Me (Salvatore Orlando), Dan Wendlandt, Josh Wilmes and Mark Voelker attended the meeting. This email is the very first action agreed during

Re: [Netstack] [Merge] lp:~netstack/quantum/quantum-unit-tests into lp:quantum

Hi Somik, thanks for your review! See my replies inline. > Great work on this changelist Salvatore! This was much needed. I do have a few > questions, while not directly related to this branch, they did bring up > questions in my mind around our official API Spec? I felt the Error codes > weren'

[Netstack] Aligning the API code with the specification

Hi all, There are currently several parts of the API implementation that are not aligned with the specification. This happened as the specification was updated while the API was being implemented, and therefore the API code now does not reflect the specification. These issues came out while dev

Re: [Netstack] Aligning the API code with the specification

?action=recall&rev=28 Your feedback is, as usual, more than welcome! The following branch has been set up to align the API specification with the implementation: https://code.launchpad.net/~salvatore-orlando/quantum/quantum-api-alignment The branch has been linked to the bug report filed yeste

Re: [Netstack] [Merge] lp:~netstack/quantum/quantum-unit-tests into lp:quantum

> Ok, If it doesn't break backward compatibility, which it doesn't seem to do, > I have no issue with this change. It did. At least it required a new options parameter of the __init__ method of the plugin. I updated the branch and restored quantum_plugin_base as it was before. In the future, if

[Netstack] [Merge] lp:~netstack/quantum/quantum-unit-tests into lp:quantum

The proposal to merge lp:~netstack/quantum/quantum-unit-tests into lp:quantum has been updated. Status: Approved => Merged For more details, see: https://code.launchpad.net/~netstack/quantum/quantum-unit-tests/+merge/68308 -- https://code.launchpad.net/~netstack/quantum/quantum-unit-tests/+

Re: [Netstack] Quantum API question - port creation

Hi Troy, This is a very good point in light of the work I'm doing for making sure the API specification is consistent with its implementation. Consistency with Openstack API is one of the reasons for which the specification states that port creation should happen asynchronously (as well as ot

[Netstack] Launchpad: The meaning of "Fix Committed" for bugs

Hi all, I think the definition of "Fix Committed" is quite unclear. I've noticed in Quantum developers are updating bugs to this state when a patch/branch is attached. I think the approach in nova, and generally in other Openstack and Launchpad projects, is to update the bug to "fix committed" w

Re: [Netstack] reviews, merges, and next steps

Hi, I would like to add that the branch that fixes most of the failing tests is: https://code.launchpad.net/~salvatore-orlando/quantum/quantum-api/+merge/65979 This branch has been waiting for a review for a week now. The "needs fixing" vote that you see on the merge proposal is re

Re: [Netstack] reviews, merges, and next steps

sistent with the Openstack API, and I would be more than happy to receive your feedback. Cheers, Salvatore From: Dan Wendlandt [mailto:d...@nicira.com] Sent: 30 July 2011 04:04 To: Somik Behera Cc: Salvatore Orlando; Santhosh Kumar M; netstack@lists.launchpad.net Subject: Re: [Netstack] reviews,

Re: [Netstack] reviews, merges, and next steps

I completely agree on freezing the API specification and label it as 'v1'. If we don't do that, it would be like chasing a moving target. Salvatore From: Somik Behera [mailto:so...@nicira.com] Sent: 31 July 2011 17:53 To: Salvatore Orlando Cc: Dan Wendlandt; Santhosh Ku

Re: [Netstack] Quantum API question - port creation

in the plugin interface thus breaking bw compatibility; * Enforce the behaviour in the API immediately, possibly choosing an asynchronous model. Regards, Salvatore From: Dan Wendlandt [mailto:d...@nicira.com] Sent: 27 July 2011 18:42 To: Troy Toman Cc: Salvatore Orlando; netstack@lists.launchpad.

Re: [Netstack] [Merge] lp:~raxnetworking/quantum/api_extensions into lp:quantum

Replies inline. Cheers, Salvatore >From the code it seems the implementation allows for defining new resources, >extending quantum core API resources, and adding actions to Core API >resources. It was my understanding that in the NetStack meeting we kind of >agreed extensions will not alter

Re: [Netstack] quantum unit-test rampup

Hi Dan, >From what you report it seems you are trying to run tests with venv enabled. I have never experienced the failure you report with greenlet, but it seems due to the fact that python development libraries are missing. The package should be python-dev in debian-based distros, python-devel i

Re: [Netstack] quantum unit-test rampup

Hi again Dan, Sorry about my previous reply. I did not realize you sent another message in the meanwhile. Several tests in lp:~netstack/quantum/quantum-unit-tests fail because of bugs which have then been fixed in the meanwhile. In the trunk branch, lp:quantum, only 4 tests fail. The fixes for

[Netstack] Aligning API implementation with specification

if no attachment is plugged into a port should we raise an error? - Plugging an attachment in port whose state is 'DOWN'. I think this should be disallowed, and an exception raised. What's your opinion? The code currently diverges from the API. Realignment is being done i

Re: [Netstack] Aligning API implementation with specification

If we are planning to lock down our API v1.0 before Diablo-4, we can just target the API blueprint to D-4. Salvatore From: Dan Wendlandt [mailto:d...@nicira.com] Sent: 02 August 2011 22:15 To: Salvatore Orlando Cc: netstack@lists.launchpad.net Subject: Re: [Netstack] Aligning API implementation

[Netstack] Quantum API resource status proposal

Following the discussion on synchronous vs asynchronous behaviour in the last Netstack meeting, we agreed to send around a proposal for introducing the concept of "Resource Status". Goal: * Ensure consistent behaviour of the API w.r.t. users, meaning that the API should always behave i

Re: [Netstack] [Merge]lp:~raxnetworking/quantum/api_extensions into lp:quantum

ts. If the majority agrees on allowing resource extensions, then I will be happy to have them :). It would be good to receive feedback from Tyler and the other guys who worked on the client library as well. Cheers, Salvatore From: Ying Liu (yinliu2) [mailto:yinl...@cisco.com] Sent: 03 August 2011 0

[Netstack] Tackling authN/authZ for Diablo-4

Hi, During yesterday's meeting we agreed that we needed to have some form of authentication and authorization in Quantum for Diablo. We also agreed we will be doing Keystone integration (please correct me if I'm wrong). I think we can safely say what we will NOT deliver for Diablo: * F

Re: [Netstack] Tackling authN/authZ for Diablo-4

Thanks Dan. I'll take care of updating the blueprint. Salvatore From: Dan Wendlandt [mailto:d...@nicira.com] Sent: 03 August 2011 16:13 To: Salvatore Orlando Cc: netstack@lists.launchpad.net Subject: Re: [Netstack] Tackling authN/authZ for Diablo-4 Hi Salvatore, great summary o

Re: [Netstack] Tackling authN/authZ for Diablo-4

don't plan to have any form of network sharing for Diablo. This implies we will have a 1:n association between tenants and Quantum networks. Salvatore From: Sumit Naiksatam (snaiksat) [mailto:snaik...@cisco.com] Sent: 03 August 2011 17:21 To: Salvatore Orlando; netstack@lists.launchpad.n

Re: [Netstack] [Merge]lp:~raxnetworking/quantum/api_extensions into lp:quantum

Hi Tyler, I just tried on my dev environment from Santhosh's branch, and the URI /v0.1/extensions works. I get an empty extension list as a response, as I haven't loaded any. The 404 error might indicate that the extension middleware is not specified in the quantum pipeline in etc/quantum.co

Re: [Netstack] [Merge]lp:~raxnetworking/quantum/api_extensions into lp:quantum

ws to implement at least a clean separation between namespace as you explained in the email which started this thread. Salvatore > -Original Message- > From: Ying Liu (yinliu2) [mailto:yinl...@cisco.com] > Sent: 04 August 2011 21:09 > To: Salvatore Orlando; Santhosh Kumar

Re: [Netstack] [Merge]lp:~raxnetworking/quantum/api_extensions into lp:quantum

ed" image resource and then the original image resource through the ref-id attribute. Anyway, I don't have a very strong opinion on this topic, and I also agree that allowing direct extension of resources has its own benefits. If the majority agrees on allowing resource extensions,

Re: [Netstack] Quantum API resource status proposal

Thanks for your comments Dan. Replies inline. Cheers, Salvatore From: Dan Wendlandt [mailto:d...@nicira.com] Sent: 05 August 2011 01:25 To: Salvatore Orlando Cc: netstack@lists.launchpad.net Subject: Re: [Netstack] Quantum API resource status proposal Great write-up Salvatore, comments inline

Re: [Netstack] Quantum Packaging Proposal

Hi Tyler, I'm sorry I will not be able to help you a lot as I'm quite ignorant as far as packaging is concerned. However, if I read your proposal correctly we will have the following packages: Quantum-common Quantum-core Quantum-client +1 a distinct package for each plugin Is that correct? Al

Re: [Netstack] Quantum API resource status proposal

I agree we are definitely on the same page. Please see my reply to your comments below. Salvatore From: Dan Wendlandt [mailto:d...@nicira.com] Sent: 05 August 2011 16:14 To: Salvatore Orlando Cc: netstack@lists.launchpad.net Subject: Re: [Netstack] Quantum API resource status proposal Great

Re: [Netstack] Aligning the API code with the specification

Hi Somik, Please see my replies inline. From: Somik Behera [mailto:so...@nicira.com] Sent: 05 August 2011 21:41 To: Salvatore Orlando Cc: netstack@lists.launchpad.net Subject: Re: [Netstack] Aligning the API code with the specification Hi Salvatore, Thanks for your continued contribution to

Re: [Netstack] Aligning the API code with the specification

Hi all, Thanks for your feedback on the API. The specification is now ready to be "locked down", and the work related to ensure the code is completely compliant with it is in the quantum-api-alignment branch. (lp:~salvatore-orlando/quantum/quantum-api-aligment). Please let me know i

Re: [Netstack] Quantum API resource status proposal

tion immediately after creating the network, or will it wait for the network to be "operationally ready" and then submit the "port create" operations? I also have a few comments inline. Cheers, Salvatore From: Dan Wendlandt [mailto:d...@nicira.com] Sent: 09 August 2011 01:21 To: Sal

[Netstack] Items for today's Netstack meeting

Hi all, I would like to bring to your attention some items for Quantum I think we should discuss during today's meeting. * API specification I'm still keen on locking down the specification; by "locking down" I don't mean that we should freeze and any attempt to propose even the slight

Re: [Netstack] Tackling authN/authZ for Diablo-4

of code. Important: The client library should be updated to add an X-Auth-Token to each request. Regards, Salvatore From: netstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net [mailto:netstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net] On Behalf Of Salvat

[Netstack] CLI unit tests (and CLI improvement)

Hi, I'm writing the unit tests for CLI. Verifying successful completion of API operations implies checking the output of the CLI, which could be tedious, error-prone, and not easy to maintain. For this reason I'm thinking of introducing Cheetah templates for generating CLI output. This will sim

[Netstack] R:Re: CLI unit tests (and CLI improvement)

ibly the same. Will push patch la tr er. Dan On Thu, Aug 11, 2011 at 8:26 AM, Salvatore Orlando mailto:salvatore.orla...@eu.citrix.com>> wrote: Hi, I’m writing the unit tests for CLI. Verifying successful completion of API operations implies checking the output of the CLI, which could be

Re: [Netstack] Quantum Packaging Proposal

Hi Tyler, Thanks for taking on the packaging work. The list of packages in your proposal sounds good, I'm just not 100% sure whether we want tests in their own packages or spread across the various packages, but I wouldn't mind if we had a package specific for tests. I have two "additional"

Re: [Netstack] Quantum tenant <--> Nova ?

I haven't looked in detail at this issue yet, though I expected it would have been raised at some point. Nova has a small module, called auth_shim, that maps back nova projects to keystone tenants. I don't have code at hand at the moment, but I recall the association between tenant and projects

Re: [Netstack] D-4 drop delayed: cli appears broken in trunk

take a look at this sometime on friday so we can get the code merged: https://code.launchpad.net/~salvatore-orlando/quantum/quantum-cli-revised/+merge/72934 Thanks! Dan -- ~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com<http://www.nicira.com> |

Re: [Netstack] D-4 drop delayed: cli appears broken in trunk

It looks Sumit is still around :) From: Dan Wendlandt [mailto:d...@nicira.com] Sent: 26 August 2011 09:23 To: Salvatore Orlando Cc: netstack@lists.launchpad.net Subject: Re: [Netstack] D-4 drop delayed: cli appears broken in trunk On Fri, Aug 26, 2011 at 1:06 AM, Salvatore Orlando

Re: [Netstack] Quantum dependency

Hi Joe, The official and only Quantum repository we have at the moment is lp:quantum. Cheers, Salvatore > -Original Message- > From: netstack- > bounces+salvatore.orlando=eu.citrix@lists.launchpad.net > [mailto:netstack- > bounces+salvatore.orlando=eu.citrix@lists.launchpad.net]

[Netstack] Quantum API documentation in trunk

Hi, A quick update on status and current direction for the blueprint api-doc-in-trunk. There is a branch attached to the blueprint; this branch currently contains a skeleton for RST documents which should be used for developer docu

Re: [Netstack] API querying

Hi Dan, I 101% agree we need to add filtering on Quantum API. This is already on the roadmap for the v1.1 API blueprint I'm preparing. Netstack people: please let me know if there's something else you'd like to add to Quantum API v1.1! Other items on my roadmap (in a nutshell): - ATOM

[Netstack] FW: [Merge] lp:~danwent/nova/qmanager-new into lp:nova

Well done, Dan! Hope that silly sql migrate issue that caused the merge to fail will not be too much of a hassle :) Salvatore -Original Message- From: boun...@canonical.com [mailto:boun...@canonical.com] On Behalf Of Vish Ishaya Sent: 07 September 2011 10:13 To: mp+72...@code.launchpad.

[Netstack] Openstack API documentation - request for contribution

Hi Netstackers, While I'm completing the operation list on the API documentation book, I'd be glad if I could get some help into adding a section on extensions. Other services, such as nova-compute, have a section describing how to fetch the extension list and details for each registered extens

Re: [Netstack] Openstack API documentation - request for contribution

Orlando Cc: netstack@lists.launchpad.net Subject: Re: [Netstack] Openstack API documentation - request for contribution Glad to help. We can add to the documentation around the general extension mechanism and the plugin aware behavior. On Wed, Sep 14, 2011 at 9:02 PM, Salvatore Orlando

Re: [Netstack] Openstack API documentation - request for contribution

Just in case you want to have a look at the work-in-progress (maybe for giving an early feedback), the branch is located at: lp:~salvatore-orlando/quantum/quantum-api-doc Regards, Salvatore From: Rajaram Mallya [mailto:rajarammal...@gmail.com] Sent: 14 September 2011 17:27 To: Salvatore Orlando

Re: [Netstack] Openstack API documentation - request for contribution

r document. Best, Ying From: netstack-bounces+yinliu2=cisco@lists.launchpad.net<mailto:cisco@lists.launchpad.net> [mailto:netstack-bounces+yinliu2<mailto:netstack-bounces%2Byinliu2>=cisco@lists.launchpad.net<mailto:cisco....@lists.launchpad.net>] On Behalf Of Salva

Re: [Netstack] Launchpad -> Github transition for Quantum

Well done! Is this the repo we should pull from: git://github.com/openstack/quantum.git ? Cheers, Salvatore > -Original Message- > From: netstack- > bounces+salvatore.orlando=eu.citrix@lists.launchpad.net > [mailto:netstack- > bounces+salvatore.orlando=eu.citrix@lists.launchpad.ne

[Netstack] Preparing the next Quantum API version

Hi all, Before submitting a formal proposal for Quantum API v1.1, I think it might be worth discussing it with all the parts involved. In earlier meeting we agreed (please correct me if I'm wrong) that the we aimed at delivering a production-ready version for Quantum in the Essex release cycle.

[Netstack] Proposing sessions for Openstack design summitq

Hello fellow NetStackers, The list of proposed session at http://summit.openstack.org/sessions is filling up, and I think it is time we start proposing our own sessions as well. Actually, there are already two accepted sessions for NetStack: 1. Donabe/API models: http://summit.openstack.

Re: [Netstack] Proposing sessions for Openstack design summitq

mailto:radur...@cisco.com] Sent: 19 September 2011 16:21 To: Salvatore Orlando; netstack@lists.launchpad.net Cc: Thierry Carrez Subject: RE: [Netstack] Proposing sessions for Openstack design summitq Hello Salvatore and all: We suppose to have a Netstack track...Its good to follow-up with Thierry

Re: [Netstack] Proposing sessions for Openstack design summitq

or each service. For Load Balancing, we should keep in mind that there is already an ecosystem project (in FutureStack) covering this: Atlas-LB. Cheers, Salvatore From: Ram Durairaj (radurair) [mailto:radur...@cisco.com] Sent: 19 September 2011 16:41 To: Salvatore Orlando; netstack@lists.launc

Re: [Netstack] Proposing sessions for Openstack design summitq

We better be quick then! Dan, do you think it will be reasonable to expect to formalize a list of proposed sessions in tomorrow's meeting? Cheers, Salvatore > -Original Message- > From: netstack- > bounces+salvatore.orlando=eu.citrix@lists.launchpad.net > [mailto:netstack- > bounces+

Re: [Netstack] Proposing sessions for Openstack design summitq

than "brainstorming". What's your opinion? Salvatore From: Dan Wendlandt [mailto:d...@nicira.com] Sent: 19 September 2011 17:14 To: Salvatore Orlando Cc: Ram Durairaj (radurair); netstack@lists.launchpad.net; Thierry Carrez Subject: Re: [Netstack] Proposing sessions for Openstack

Re: [Netstack] Proposing sessions for Openstack design summitq

] Sent: 19 September 2011 17:43 To: Salvatore Orlando; Dan Wendlandt Cc: netstack@lists.launchpad.net; Thierry Carrez Subject: RE: [Netstack] Proposing sessions for Openstack design summitq On that same note: there is a Donabe session that has been registered I guess we can discuss the donabe

Re: [Netstack] Proposing sessions for Openstack design summitq

stering sessions for: * Quantum API v1.1 * AuthN/AuthZ (RBAC) * "Reference Implementation"/"Basic" plugin Cheers, Salvatore From: Dan Wendlandt [mailto:d...@nicira.com] Sent: 19 September 2011 17:45 To: Salvatore Orlando Cc: Ram Durairaj (radurair

[Netstack] R:Re: Proposing sessions for Openstack design summitq

le confusing. I think we need 2 UIs, one for managing Nova network and one for managing Quantum. The Nova network management UI can obviously proxy calls to Quantum using QuantumManager. Based on what Arvind, Mark Voelker & team think, I can register a blueprint for this discussion. Thanks, S

Re: [Netstack] Donabe meeting

No problem for me. Next Wednesday same time will be fine. Hope you had a chance to attend to the Openstack day in Paris as well! Salvatore > -Original Message- > From: netstack- > bounces+salvatore.orlando=eu.citrix@lists.launchpad.net > [mailto:netstack- > bounces+salvatore.orlando=

Re: [Netstack] API documentation ready for review

eptember 2011 19:33 To: Dan Wendlandt Cc: Salvatore Orlando; netstack@lists.launchpad.net Subject: RE: [Netstack] API documentation ready for review Hi, OK - I guess it is clear enough that the only allowed strings for port-state are ACTIVE and DOWN, and hopefully the behavior for ACTIVE or DOWN is roughl

[Netstack] Running Nova with Quantum (OVS Plugin)

Hi, I have installed an Openstack testbed with Quantum (OVS Plugin) and standard nova IPAM. Hypervisor backend is XenServer. Although I managed to get a couple of VMs for two different tenants up and running on the appropriate networks, I had to do things that I feel I shouldn't have done. I ho

Re: [Netstack] API documentation ready for review

Thanks a lot Dan for applying the last changes to the documentation! Salvatore From: Dan Wendlandt [mailto:d...@nicira.com] Sent: 23 September 2011 06:02 To: Salvatore Orlando Cc: Andy Bierman; netstack@lists.launchpad.net Subject: Re: [Netstack] API documentation ready for review Updated the

Re: [Netstack] Running Nova with Quantum (OVS Plugin)

/~salvatore-orlando/quantum/quantum-reverted/+merge/76719 Bug report: https://bugs.launchpad.net/quantum/+bug/857315 That branch also slightly changes the way in which the response for show attachment is generated. I make sure than an 'id' attribute is always added, even if there is no atta

Re: [Netstack] Proposing sessions for Openstack design summitq

Hi Ying, That sounds good. Assuming that we will get a brainstorming session (55 mins), should we work together to allocate sub-topics in the session? Salvatore From: Ying Liu (yinliu2) [mailto:yinl...@cisco.com] Sent: 27 September 2011 22:23 To: Salvatore Orlando Cc: netstack

Re: [Netstack] [Openstack] Compute API and doc

Hi, I'm completely happy to align Quantum with the other Openstack projects, and move the API documentation in a separate repo. I'm totally fine with granting +2 rights to doc-core team, and I believe that their reviews will be of great help to improve the quality of the documentation. Salvat

Re: [Netstack] Pre-summit Quantum & Dashboard integration discussions

Hi Somik, These are exactly the kind of questions I would like to answer in the session I have proposed. I don't think we need to schedule a different session in the unconference. I hope we can use this thread to precisely define the agenda of the session. Salvatore From: netstack-bounces+salv

[Netstack] Quantum API 1.1 session - proposed agenda

Hi Netstackers, It seems we will have an early start with Quantum API v1.1, Monday at 9.30. The following is a proposal for an agenda that I've put together. It will be great to have your feedback. 1. Quantum API v1.0 recap (5 minutes) 2. 'operational status' for API

[Netstack] RBAC for Quantum session - proposed agenda

Hi again Netstackers, On Tuesday morning we will be gathering again for discussing what we should with Authorization in Quantum. Please note that I'm assuming that we will be using Keystone as our identity service; if you feel differently this is right session for discussing your concerns. For

[Netstack] Quantum "Reference Implementation" plugin session - proposed agenda

Hi again, On Wednesday at 2PM we will be discussing the possibility of implementing a plugin that could be considered as a reference implementation of the Quantum API. The goal of this session, and the related work, is to have a plugin which can be easily deployed by any Quantum user, regardles

Re: [Netstack] Data extensions in quantum

I don't have yet performed a complete review. Anyway, I was wondering whether we can avoid breaking existing plugins by using **kwargs, and not removing existing parameters Example: create_network(self, tenant_id, net_name, **kwargs) I also think Ying had another important point on how the API

[Netstack] Blueprint for updating API framework

Hi, I've registered a blueprint regarding the Quantum API framework: https://blueprints.launchpad.net/quantum/+spec/api-framework-essex Our framework currently diverges from Nova's Openstack API framework. I think that there are several benefits in realigning them: 1. We get a much clean

[Netstack] 'Basic VLAN' plugin - some thoughts

Hi all, I put some thoughts regarding the design and the implementation of this plugin on a wiki page: http://wiki.openstack.org/Quantum-BasicVlanPlugin Please let me have your feedback. If everything goes according to plan, I plan to start implementing this plugin in two weeks' time. Regards,

Re: [Netstack] 'Basic VLAN' plugin - some thoughts

7;m being quite optimistic. For more detailed replies, please see inline! From: Sumit Naiksatam (snaiksat) [mailto:snaik...@cisco.com] Sent: 17 October 2011 16:09 To: Salvatore Orlando; netstack@lists.launchpad.net Subject: RE: [Netstack] 'Basic VLAN' plugin - some thoughts Hi Salvatore, Th

[Netstack] FW: [Openstack] Change to api-paste.ini

Is this something we might consider for Quantum as well as concerns resource extensions? Salvatore -Original Message- From: openstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net [mailto:openstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net] On Behalf Of

Re: [Netstack] Code coverage status

+1 > -Original Message- > From: netstack- > bounces+salvatore.orlando=eu.citrix@lists.launchpad.net > [mailto:netstack- > bounces+salvatore.orlando=eu.citrix@lists.launchpad.net] On Behalf Of > Brad Hall > Sent: 18 October 2011 16:06 > To: Dan Wendlandt > Cc: netstack@lists.launchp

Re: [Netstack] Code coverage status

Hi Brad, Thanks for this very important piece of code. I think we should also try and enforce coverage checks in Jenkins (e.g.: if coverage for a module drops below 80% reject commit). What's your opinion? Salvatore > -Original Message- > From: netstack- > bounces+salvatore.orlando=eu.

Re: [Netstack] Changing the update_{network,port} calls

Thanks Brad for starting the discussion on this important point. Some comments inline. Salvatore From: netstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net [mailto:netstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net] On Behalf Of Dan Wendlandt Sent: 19 October 2

Re: [Netstack] Wiki page for operational status in Quantum API

Hi Dan, Thanks for your feedback! Replies inline. From: Dan Wendlandt [mailto:d...@nicira.com] Sent: 20 October 2011 03:40 To: Salvatore Orlando Cc: netstack@lists.launchpad.net Subject: Re: [Netstack] Wiki page for operational status in Quantum API On Wed, Oct 19, 2011 at 4:19 AM, Salvatore

Re: [Netstack] Wiki page for operational status in Quantum API

: Sumit Naiksatam (snaiksat) [mailto:snaik...@cisco.com] Sent: 20 October 2011 17:22 To: Salvatore Orlando; Dan Wendlandt Cc: netstack@lists.launchpad.net Subject: RE: [Netstack] Wiki page for operational status in Quantum API Hi Salv, Echo Dan's suggestions and comments, great write-up. J

Re: [Netstack] Nova network parity

As I'm working on supporting security groups in the XenAPI backend in nova, I reckon I can contribute on the blueprints for security groups. Blueprint: https://blueprints.launchpad.net/quantum/+spec/network-parity-sg > > - Security groups: security groups as implemented with iptables or > > l

[Netstack] info on api-framework-essex blueprint

Hello netstackers, The branch for the blueprint https://blueprints.launchpad.net/quantum/+spec/api-framework-essex is about to be proposed for merge. Before doing that, I'd like to ask the community whether it makes more sense to update the framework for core API and extensions in a single bran

Re: [Netstack] info on api-framework-essex blueprint

] On Behalf Of Salvatore Orlando Sent: 02 November 2011 00:08 To: netstack@lists.launchpad.net Subject: [Netstack] info on api-framework-essex blueprint Hello netstackers, The branch for the blueprint https://blueprints.launchpad.net/quantum/+spec/api-framework-essex is about to be proposed for

Re: [Netstack] Fwd: Change in openstack/quantum[master]: blueprint quantum-packaging

ailto:b...@nicira.com>> Gerrit-Reviewer: Edgar Magana Perdomo mailto:eperd...@cisco.com>> Gerrit-Reviewer: Jenkins Gerrit-Reviewer: Salvatore Orlando Gerrit-Reviewer: Tyler Smith mailto:tyles...@cisco.com>> Gerrit-Reviewer: dan wendlandt mailto:d...@nicira.com>> -

[Netstack] Quantum unit tests and distributed

Hi, After pulling from quantum master I saw run_tests.sh was only running the tests in client.lib.quantum.tests, unless tests were executed with the virtual env. I realized that the cause was the distribute package, which is required by nose. Ubuntu oneirc comes with distribute 0.6.16, whereas t

Re: [Netstack] Howto retrieve a server's VIF

Hi Joacim, Thanks for your interest in Quantum. If you are using nova with the Quantum Network Manager (--network_manager = nova.network.quantum.manager), then the manager will take care of plugging the VIF into the network for you. In this case you will not have to explicitly perform a PUT on

[Netstack] Quantum Operational Status

Hi netstackers, Just a quick update that, following your feedback, the specification for the Operational Status blueprint has been updated. You can find it here: http://wiki.openstack.org/QuantumOpStatus (the spec has also been associated with the blueprint, which can be found here: https://blue

[Netstack] Blueprint API-operational-status

Hi Netstackers, I have pushed for review a proposal for the operational status blueprint. The changeset is available here: https://review.openstack.org/#change,2097 Please note that this changeset is stacked upon api-framework-essex, which is still waiting for an approval after the reviewers' c

Re: [Netstack] error codes in quantum api

in the HTTP response. Regards, Salvatore From: Aaron Lee [mailto:aaron@rackspace.com] Sent: 06 December 2011 22:42 To: netstack@lists.launchpad.net Cc: Salvatore Orlando; Dan Wendlandt Subject: Re: error codes in quantum api Dan, Salvatore, folks, The issue I've seen with this was an error

[Netstack] Quantum Manager fails to delete networks

Just noticed this bug submitted for nova: https://bugs.launchpad.net/nova/+bug/902175 It seems that Isaku spotted an incorrect behaviour in the VIF drivers. As unplug is currently unimplemented, delete networks operation on Quantum networks will fail because the VIF would still be 'logically' p

[Netstack] Specification for filters in quantum api

Hi, A full spec is now available for the API-filters blueprint. You can find it at http://wiki.openstack.org/quantum-api-filters or checking the blueprint itself. Regards, Salvatore -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https:/

Re: [Netstack] error codes in quantum api

des in v1.0, and provide the new ones in v1.1. This would definitely break backward compatibility for clients written for API v1.0; hence we should also consider branding this new version 2.0. What are your thoughts? Regards, Salvatore From: Dan Wendlandt [mailto:d...@nicira.com] Sent: 09 December 2

Re: [Netstack] cloudpipe stuff

Ideally I would choose the 2nd route as well. However, this kind of reminds me of the discussions we were having at the design summit over whether we should rely on a new service/extension of the Quantum API for achieving feature parity (e.g. The ‘L3 service’) or try to re-use as much as possibl

Re: [Netstack] Specification for filters in quantum api

t-pushable). Salvatore From: Dan Wendlandt [mailto:d...@nicira.com] Sent: 03 January 2012 01:45 To: Salvatore Orlando Cc: netstack@lists.launchpad.net Subject: Re: [Netstack] Specification for filters in quantum api One other related point is that these filters are going to be in 1.1 only, w

Re: [Netstack] Specification for filters in quantum api

itrix@lists.launchpad.net [mailto:netstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net] On Behalf Of Salvatore Orlando Sent: 09 January 2012 15:04 To: Dan Wendlandt Cc: netstack@lists.launchpad.net Subject: Re: [Netstack] Specification for filters in quantum api Hi, First of all, apologies for a

Re: [Netstack] error codes in quantum api

A full specification is now available at http://wiki.openstack.org/quantum-api-error-codes Salvatore From: Dan Wendlandt [mailto:d...@nicira.com] Sent: 11 January 2012 21:21 To: Salvatore Orlando Cc: Aaron Lee; netstack@lists.launchpad.net Subject: Re: error codes in quantum api btw, based on

Re: [Netstack] error codes in quantum api

Code is now available for review at: https://review.openstack.org/#change,3101 Salvatore From: Dan Wendlandt [mailto:d...@nicira.com] Sent: 12 January 2012 16:53 To: Salvatore Orlando Cc: Aaron Lee; netstack@lists.launchpad.net Subject: Re: error codes in quantum api Great spec Salvatore. No

Re: [Netstack] Specification for filters in quantum api

Aaaron's comments on the gerrit review have been addressed. You can find the latest changeset here: https://review.openstack.org/#change,2968,patchset=3 Salvatore From: Salvatore Orlando Sent: 09 January 2012 17:59 To: Salvatore Orlando; Dan Wendlandt Cc: netstack@lists.launchpad.net Su

  1   2   >