Thanks Jason, we're definitely on the same page.  A few comments in line.<div><br></div><div>Dan<br><br><div class="gmail_quote">On Tue, Jul 12, 2011 at 8:52 AM, Jason Kölker <span dir="ltr"><<a href="mailto:jkoelker@rackspace.com">jkoelker@rackspace.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Mon, 2011-07-11 at 19:33 -0700, Dan Wendlandt wrote:<br>
> Given that we're reworking the commands (and potentially breaking peoples'<br>
> scripts), it might make sense to add a "type" field to the "network create"<br>
> command to provide future flexibility to introducing different types of<br>
> networks that can be created by nova-manage, particularly Quantum networks.<br>
><br>
> Nova's existing model of L2 networking is very specific to Linux bridging<br>
> and fields like  [VLAN_START] [FLAT_NETWORK_BRIDGE]<br>
> [BRIDGE_INTERFACE] don't really make sense, but other fields will.<br>
<br>
</div>I would think that type would be inferred by which network_manager is<br>
running, but I'm not opposed to adding it. I could see it being useful<br>
to trigger a separate subcommand for arguments something like:<br>
<br>
nova-manage network create TYPE [...]<br>
<br>
Then depending on type the rest of the flags would change so we would<br>
have:<br>
<br>
nova-manage network create nova [VLAN_START] [FLAT_NETWORK_BRIDGE]<br>
[BRIDGE_INTERFACE]<br>
<br>
and<br>
<br>
nova-manage network create quantum [QUANTUM_SPECIFIC_OPTION, ...]<br></blockquote><div><br></div><div>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. </div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
The only thing I'm concerned about then is the divergence of the api<br>
entry to the network_manager(s) and ending up with overloaded command<br>
structures like we currently have.<br>
<br>
I would really like to see the network_management functions completely<br>
removed from nova proper and the current network_managers repackaged as<br>
a "reference implementation". Interaction with the network_manager<br>
to/from nova should only occur over the rpc mechanism through a defined<br>
protocol. In this situation, I think each network_management<br>
implementation would have its own command set.<br></blockquote><div><br></div><div>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.  </div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> It would be great to coordinate these changes.  Do you know when you expect<br>
> your branch (<br>
> <a href="https://code.launchpad.net/~jason-koelker/nova/separate_networks" target="_blank">https://code.launchpad.net/~jason-koelker/nova/separate_networks</a>, I<br>
> believe?) to hit?<br>
<br>
</div>I have a little bit more cleaning up to do, mainly just the commands,<br>
then some testing, hopefully by the end of the week or early next week<br>
I'll be ready to merge-prop it.<br>
<div><div></div><div class="h5"><br>
Happy Hacking!<br>
<br>
7-11<br>
--<br>
A. Because it breaks the logical sequence of discussion<br>
Q. Why is top posting bad?<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <br>Nicira Networks, Inc. <br><a href="http://www.nicira.com">www.nicira.com</a> | <a href="http://www.openvswitch.org">www.openvswitch.org</a><br>

Sr. Product Manager <br>cell: 650-906-2650<br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br><br>
</div>