[Openstack] nova-manage network modifications feedback request

Jason Kölker jkoelker at rackspace.com
Tue Jul 12 15:52:14 UTC 2011


On Mon, 2011-07-11 at 19:33 -0700, Dan Wendlandt wrote:
> Given that we're reworking the commands (and potentially breaking peoples'
> scripts), it might make sense to add a "type" field to the "network create"
> command to provide future flexibility to introducing different types of
> networks that can be created by nova-manage, particularly Quantum networks.
>
> Nova's existing model of L2 networking is very specific to Linux bridging
> and fields like  [VLAN_START] [FLAT_NETWORK_BRIDGE]
> [BRIDGE_INTERFACE] don't really make sense, but other fields will.

I would think that type would be inferred by which network_manager is
running, but I'm not opposed to adding it. I could see it being useful
to trigger a separate subcommand for arguments something like:

nova-manage network create TYPE [...]

Then depending on type the rest of the flags would change so we would
have:

nova-manage network create nova [VLAN_START] [FLAT_NETWORK_BRIDGE]
[BRIDGE_INTERFACE]

and

nova-manage network create quantum [QUANTUM_SPECIFIC_OPTION, ...]

The only thing I'm concerned about then is the divergence of the api
entry to the network_manager(s) and ending up with overloaded command
structures like we currently have.

I would really like to see the network_management functions completely
removed from nova proper and the current network_managers repackaged as
a "reference implementation". Interaction with the network_manager
to/from nova should only occur over the rpc mechanism through a defined
protocol. In this situation, I think each network_management
implementation would have its own command set.

> It would be great to coordinate these changes.  Do you know when you expect
> your branch (
> https://code.launchpad.net/~jason-koelker/nova/separate_networks, I
> believe?) to hit?

I have a little bit more cleaning up to do, mainly just the commands,
then some testing, hopefully by the end of the week or early next week
I'll be ready to merge-prop it.

Happy Hacking!

7-11
-- 
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?





More information about the Openstack mailing list