Open Stack

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