Thanks Jason,<div><br></div><div>Not to discourage adventurous people from playing with Melange, but the most reliable and tested way of using Quantum + Nova in terms of the Essex release is to use the built in Nova IPAM (which is the default when using QuantumManager). </div>
<div><br></div><div>We'll be shifting over to using a merged Quantum + Melange in Folsom, but in the mean time, I wouldn't suggest that end users should deploy Melange unless they are already familiar with Melange and/or willing to get their hands dirty. </div>
<div><br></div><div>Dan</div><div><br>p.s. For those who DO want to get your hands dirty, two things I've noticed from playing around with Quantum + Melange in devstack:</div><div><br></div><div>1) I seem to have to turn off the firewall driver to avoid an exception in the virt layer when using melange and libvirt. This can be done by setting "firewall_driver = nova.virt.firewall.NoopFirewallDriver" in nova.conf . </div>
<div><br></div><div>2) DHCP with Melange + Nova is not well tested. I believe I saw a bug filed on it in the past with networks that are owned by the "default" tenant. I don't think this has been fixed. <br>
<br><br><div class="gmail_quote">On Wed, Mar 28, 2012 at 9:29 AM, Jason Kölker <span dir="ltr"><<a href="mailto:jkoelker@rackspace.com" target="_blank">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">
Hi Mandar,<br>
<br>
Thanks for taking the time to look into Melange! Currently Nova +<br>
Quantum + Melange is in a huge state of development flux. The current<br>
code gets us enough to play with some features and be backwards<br>
compatible with all the features in the "legacy" network managers. In<br>
the Folsom development cycle many things in regards to QuantumManager<br>
will be changing. See below for (some) specifics.<br>
<div><br>
On Wed, 2012-03-28 at 05:20 -0700, Mandar Vaze wrote:<br>
> I've setup nova+quantum+mélange using devstack.<br>
> devstack creates networks using tenant_id ="default" (This in itself<br>
> looks incorrect, since it should be valid UUID for one of the tenant<br>
> from keystone DB - but I can imagine that stack.sh can't get UUID for<br>
> demo or admin tenants easily)<br>
<br>
</div>Since nova-manage doesn't do any auth, the project_id in the call to<br>
create the initial network is None, this triggers the QuantumManager to<br>
fall back to using the value of FLAGS.quantum_default_tenant_id which<br>
defaults to the value 'default'.<br>
<br>
There really isn't a good way to get around this right now (without<br>
manually specifying the project_id as mentioned below). Since some data<br>
is stored in the Nova networks table, some in melange and some<br>
(possibly) by whatever quantum plugin is running.<br>
<br>
In the next iteration, using nova-manage to create Quantum/Melange<br>
blocks magically in the background will be removed, and will require<br>
that each service be setup through their native tools/apis.<br>
<div><br>
> So I updated nova.networks, quantum.networks and mélange.ip_blocks<br>
> tables manually and put tenant_id to use UUID of the "demo" tenant.<br>
> Question : What is the right way to create network entries for "demo"<br>
> tenant, that are used by nova/quantum as well as mélange DB ?<br>
<br>
</div>I think (although never tried) you can pass --project_id to nova-manage<br>
and it should create it with the right tentat_id.<br>
<div><br>
> (I tried "mélange ip-block create" for <a href="http://10.0.0.0/24" target="_blank">10.0.0.0/24</a> but I got an error<br>
</div>> that that cidr is already being used (by tenant_id="default") - so I<br>
<div>> updated the DB manually. Also this would work only take care of<br>
> mélange DB - what about nova and quantum DB ?)<br>
<br>
</div>You can pass the -t flag to the melange cli to switch the tenant name.<br>
The quantum and nova db's will need to be updated manually at the<br>
moment.<br>
<div><br>
> Once I did these changes, my instances could not launch, they would<br>
> get stuck in Networking/Error state - with "NetworkNotFound" error in<br>
> the logs for network UUID which I know is valid for tenant "demo"<br>
<br>
</div>So depending on where the error was poping up at, it might have been<br>
that it was getting a UUID where the code was expecting the network id<br>
from the nova table.<br>
<br>
This is part of the problem of having 3 masters of information, and work<br>
has begin to reduce this to 2 and eventually just 1 with melange merging<br>
with quantum.<br>
<div><br>
> Tracing this further, I came across the following code which tries to<br>
> "get_allocated_ips" for "default" tenant, before user specified<br>
> project_id<br>
> In my opinion, this is incorrect.<br>
> Once I switched the order i.e. try project_id before "default"<br>
> everything started working.<br>
><br>
> Please comment whether the following code change makes sense (I'm not<br>
> even sure, if I were to submit this code change - what would I write<br>
> in the bug description - hence need comments from you)<br>
><br>
> diff --git a/nova/network/quantum/melange_ipam_lib.py b/nova/network/quantum/melange_ipam_lib.py<br>
> index c68d83c..ea39f60 100644<br>
> --- a/nova/network/quantum/melange_ipam_lib.py<br>
> +++ b/nova/network/quantum/melange_ipam_lib.py<br>
> @@ -152,7 +152,8 @@ class QuantumMelangeIPAMLib(object):<br>
><br>
> def get_tenant_id_by_net_id(self, context, net_id, vif_id, project_id):<br>
> ipam_tenant_id = None<br>
> - tenant_ids = [FLAGS.quantum_default_tenant_id, project_id, None]<br>
> + #tenant_ids = [FLAGS.quantum_default_tenant_id, project_id, None]<br>
> + tenant_ids = [project_id,FLAGS.quantum_default_tenant_id, None]<br>
> # This is confusing, if there are IPs for the given net, vif,<br>
> # tenant trifecta we assume that is the tenant for that network<br>
> for tid in tenant_ids:<br>
<br>
</div>The order shouldn't matter since the idea is to match the first block<br>
that the network exists in. The problem is that its triggering moving on<br>
to the next block in the list via a KeyError which won't be caught if<br>
the default_tenant_id lookup throws a 404 (which it will if the block<br>
doesn't exist ;).<br>
<br>
If you change the `except KeyError` to `except Exception` since the<br>
melange_connection raises a bare Exception when the response is > 400.<br>
<br>
I filed bug 967261 at <a href="https://bugs.launchpad.net/nova/+bug/967261" target="_blank">https://bugs.launchpad.net/nova/+bug/967261</a> and<br>
submitted the fix at <a href="https://review.openstack.org/5912" target="_blank">https://review.openstack.org/5912</a> .<br>
<br>
The current QuantumManger tries (much like nova) to be very flexible and<br>
make no assumptions about how things are setup. I've been playing with a<br>
new network manager that I would like to see as the next iteration of<br>
Quantum + Melange + Nova that is very opinionated and stripped down. It<br>
assumes you are using melange and quantum only, it only communicates<br>
with nova over rpc (no nova db tables are used on the network manager<br>
side of things), and totally punts on DHCP support (really this needs to<br>
be move into quantum/melange anyway). I've uploaded a snapshot to<br>
<a href="https://github.com/jkoelker/nova/compare/the_deuce" target="_blank">https://github.com/jkoelker/nova/compare/the_deuce</a> it currently is<br>
usable (and I've gotten devstack to use it once ;) but still should be<br>
considered like double super pre-alpha beta.<br>
<br>
Happy Hacking!<br>
<br>
7-11<br>
<span><font color="#888888"><br>
<br>
--<br>
Mailing list: <a href="https://launchpad.net/~netstack" target="_blank">https://launchpad.net/~netstack</a><br>
Post to : <a href="mailto:netstack@lists.launchpad.net" target="_blank">netstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~netstack" target="_blank">https://launchpad.net/~netstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira Networks: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br><div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div><br>
</div>