Open Stack

Thanks Jason, we're definitely on the same page.  A few comments in line.

Dan

On Tue, Jul 12, 2011 at 8:52 AM, Jason Kölker <jkoelker at rackspace.com>wrote:

> 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, ...]
>

Yup, that was my main motivation.  I agree that the network manager could
try to infer, but it seems cleaner to be able to cleanly separate out the
commands.  If we decide to keep network creation in the main nova-manage
command long-term, this seems like the right approach.


>
> 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.
>

I completely agree.  Glad to hear you see the world that way as well :)  I'm
in the process of putting together some materials that describe this
proposal and would love to get your thoughts when I'm done.  If you have
anything written up on this already, please let me know.



>
> > 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?
>
>


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira Networks, Inc.
www.nicira.com | www.openvswitch.org
Sr. Product Manager
cell: 650-906-2650
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110712/9404ee6d/attachment.html>