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 : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
