Merge lp:~ntt-pf-lab/nova/network-service into lp:~midokura/nova/network-service

Proposed by Hisaharu Ishii
Status: Merged
Merged at revision: 826
Proposed branch: lp:~ntt-pf-lab/nova/network-service
Merge into: lp:~midokura/nova/network-service
Diff against target: 19 lines (+3/-6)
1 file modified
bin/nova-network-manage (+3/-6)
To merge this branch: bzr merge lp:~ntt-pf-lab/nova/network-service
Reviewer Review Type Date Requested Status
Ryu Ishimoto Approve
Devin Carlen (community) Approve
Matt Dietz (community) Approve
Review via email:

Description of the change

Fixed debug coding in nova-network-manage

To post a comment you must log in.
Revision history for this message
Matt Dietz (cerberus) wrote :

Normally these kinds of things should probably have bugs associated with them for tracking.

Looks good, though

review: Approve
Revision history for this message
Devin Carlen (devcamcar) wrote :


review: Approve
Revision history for this message
termie (termie) wrote :

why are we using environment variables here instead of command-line arguments?

Revision history for this message
Ryu Ishimoto (ryu-midokura) wrote :

It's using the env variables mainly for consistency with novaclient tool. I think it would work either way.

Revision history for this message
Ryu Ishimoto (ryu-midokura) wrote :

Thanks for catching this. Will merge.

review: Approve
Revision history for this message
termie (termie) wrote :

Shouldn't we be being consistent with nova, not novaclient?

Revision history for this message
Ryu Ishimoto (ryu-midokura) wrote :

In this case, this client, even though it's called nova-manage-network, it's doing something a bit different from nova-manage in that it's simply making REST API calls to the nova-api server as opposed to updating DB records directly from the script. The only other client tool in Nova that I was aware of that does something similar was novaclient so I just implemented it the same way. This branch is also experimental, and it's here just to showcase that the network services can be pluggable The new (less disruptive) way to do this is being developed in lp:~midokura/nova/network-refactoring.

And I completely agree that we need to make everything as consistent as possible to Nova, which is one of the main focuses in the new branch.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'bin/nova-network-manage'
2--- bin/nova-network-manage 2011-04-16 07:42:02 +0000
3+++ bin/nova-network-manage 2011-04-21 06:28:49 +0000
4@@ -85,12 +85,9 @@
6 NOVA_FLAGS = nova_flags.FLAGS
8-## OS_CLIENT = net_client.NetOpenStack(os.environ['NOVA_USERNAME'],
9-## os.environ['NOVA_API_KEY'],
10-## os.environ['NOVA_URL'])
11-OS_CLIENT = net_client.NetOpenStack('ryu',
12- 'b3573cfc-9c21-4345-a601-8f17a04d43a1',
13- 'http://localhost:8774/v1.0')
14+OS_CLIENT = net_client.NetOpenStack(os.environ['NOVA_USERNAME'],
15+ os.environ['NOVA_API_KEY'],
16+ os.environ['NOVA_URL'])
18 class NetworkCommands(object):
19 """Class for managing network."""


People subscribed via source and target branches

to status/vote changes: