Open Stack

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



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira Networks: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120328/4622631a/attachment.html>