openstack team mailing list archive

[Markus Barth <launchpad.net@xxxxxxxxx>]

On May 29, 2013, at 11:39 PM, Chris Behrens <cbehrens@xxxxxxxxxxxx> wrote:
> On May 28, 2013, at 8:38 PM, Markus Barth <launchpad.net@xxxxxxxxx> wrote:
>
> > Hello everyone,
> >
> > Nova-cells filter has been merged now, so I'd like to make use of them
> > and set up an installation for a proof of concept.
> >
> > My goal is to create new filters and then spawn instances in a demo.
>
> Awesome.  I'd be happy to assist you here with your current (and future) questions.

Yay!

> > Setup:
> > - Global: Horizon, Keystone, Glance
> > - API cell: nova-api, nova-conductor, nova-cells, nova-network (flat),
> > mysql, rabbitmq
> > - child cells: nova-cells, nova-conductor, nova-cert, nova-scheduler,
> > nova-compute-qemu; cinder-*, mysql, rabbitmq
>
> There's a number of limitations with cells right now, and the above won't *quite* work… but close.  The only issue that I see above is with cinder and nova-network.  Further info below.
>
> > 1. Is the above all services I need to spawn instances from Horizon
> > without errors?
>
> Generally, yes.. those are the correct services in the correct cells… *except* nova-network *might* work, but it would have to be in each child cell and you'd need different IP blocks configured in each nova-network in order to work.  They can all be the same layer 2 network, however.  The limitation is because compute needs to talk to nova-network via RPC in order to assign IP addresses…  and RPC communication between nova-compute and other services is intra-cell only.  And if you tried to configure the same /24 in 2 different child cells, since they are separate DBs, you'll get the same IPs handed out in multiple child cells.  More below under #3.

I did think of that, but since Horizon needs to get a tenant's networks 
from a single quantum-server, I thought I'd make Quantum a global 
installation.
I know instances would not get IP adresses, but I don't actually need 
them to.

I'm currently planning that the global services and each cell are in 
separate subnets.

I guessed if there was Quantum in each cell it would be impossible for 
Horizon to talk to all of them and then join the configured networks in 
all cells into one.
Or would it be enough to have a global quantum database with Quantum in 
each cell and Horizon pointing to a random (or an additional global) 
installation to have Quantum working? Then nova-compute can actually use 
the local Quantum.

> > 2. Do I need cinder-* (or nova-volume)? Is it really optional now?
>
> No, you do not need them if you use local storage for your VMs.  In fact, cinder does not currently work with cells.  I have a patch for this that I need to clean up and submit.
>
> > 3. Do I need nova-network (or quantum-*)? I know quantum-* does not have to run when spawning instances, but I guess I need it to create a
> > network for a tenant in the first place!?
>
> Quantum is a better choice vs nova-network with or without cells...as nova-network will be deprecated some day (AFAIK).  If you choose Quantum, you can set this up as a global service to use with cells as long as all of your child cells are on the same layer 2 network.  IP address assignments would be managed globally, etc.  If you choose quantum and set it up globally, the API (nova-api) extensions for networking should work.  In the future, we'll need to find a good way to allow Quantum to work with a config such that different cells can be on different layer 2 networks.

Then Quantum it is. I just thought I'd keep it simple and go with 
nova-network and probably avoid some problems.

> Hope that helps so far,

It really does, thanks!

Markus