[Openstack] nova cells minimal setup
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. 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 1. Is the above all services I need to spawn instances from Horizon without errors? 2. Do I need cinder-* (or nova-volume)? Is it really optional now? 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!? Thanks for your help 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
Re: [Openstack] nova cells minimal setup
On May 28, 2013, at 8:38 PM, Markus Barth 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. > > 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. > > 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. Hope that helps so far, - Chris ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] nova cells minimal setup
On May 29, 2013, at 11:39 PM, Chris Behrens wrote: On May 28, 2013, at 8:38 PM, Markus Barth 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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] nova cells minimal setup
On 30/05/13 00:18, Markus Barth wrote: > > On May 29, 2013, at 11:39 PM, Chris Behrens wrote: >> >> On May 28, 2013, at 8:38 PM, Markus Barth >> 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