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