On 30/05/13 00:18, Markus Barth wrote: > > On May 29, 2013, at 11:39 PM, Chris Behrens <cbehr...@codestud.com> wrote: >> >> On May 28, 2013, at 8:38 PM, Markus Barth <launchpad....@boecht.de> >> 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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
