openstack team mailing list archive

[Tom Fifield <fifieldt@xxxxxxxxxxxxxx>]

On 30/05/13 00:18, Markus Barth wrote:
> 
> 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.

FWIW, NeCTAR uses nova-network in flat DHCP multihost HA mode without
problems. As Chris says, each site needs separate IP ranges though :)

> 
>> Hope that helps so far,
> 
> It really does, thanks!
> 
> Markus
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>