OpenStack Compute (nova)

MultiCluster Zones in Cactus - how to configure for multiple users

Asked by Claire McDay

Hi Folks,
I’m trying to set up a simple zone configuration on Cactus such that there is a parent zone (Z1) with no compute servers and 2 child zones (Z2 & Z3). I want different users (Alice & Bob) to be able to submit requests into Z1 and have those result in instances starting in either Z2 or Z3. I’ve read the Blueprint https://blueprints.launchpad.net/nova/+spec/multi-cluster-in-a-region and the notes in the Developer Guide http://nova.openstack.org/devref/zone.html, and I’ve managed to get to the state where zone-info in Z1 shows Z2 and Z3. However I’m a bit stuck to understand how to go from here. Specifically:
1) When adding Z2 and Z3 to Z1 I’m assuming that I have to specify the admin details for those zones (as there’s only one set and I want to be able to use the set-up with mutliple users). Is that right ?

2) What scheduler flags do I need, and how do I configure which requests go to which child zone ?

3) Do I need to create account for Alice and Bob in all 3 Zones – or is there some way to pass them from Z1 to Z2 and Z3 ?

4) If I try to start an instance for Alice in project A-Proj1, do I need to have A-Proj1 created for Alice in all 3 zones, or will the scheduler in Z1 find which child zone has the combination of Alice and A-Proj1 ?
Thanks
Claire

Question information

Language:
English Edit question
Status:
Answered
For:
OpenStack Compute (nova) Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Sandy Walsh (sandy-walsh) said : 		#1

For Zones (and Distributed Scheduler) I would recommend using Trunk for the latest additions and bug fixes.

There are also additional docs for Distributed Scheduler which talk about the flags and their usage.

1. Correct, use admin credentials. This will change when Keystone is integrated with Nova.

2. When the --enable_zone_routing flag is set, any attempt to look for an instance in the current zone that fails will automatically reroute to the child zones.

I use (this is all spelled out in the dist scheduler docs)
  --allow_admin_api=true
  --enable_zone_routing=true
  --zone_name=zone1
  --build_plan_encryption_key=c286696d887c9aa0611bbb3e2025a45b <-- change
  --scheduler_driver=nova.scheduler.host_filter.HostFilterScheduler
  --default_host_filter=nova.scheduler.host_filter.AllHostsFilter

3. Currently, all operations done in child zones are done using the admin account specified when you added the zone. Again, this will change with Keystone integration as Auth will live above all Zones.

4. Yes, the project needs to live in all zones. Again, this will change with keystone integration.

Hope it helps!

Revision history for this message
Claire McDay (claire-mcday) said : 		#2

Hi Sandy,

Thanks for taking the time to reply.

> 2. When the --enable_zone_routing flag is set, any attempt to look for an instance
> in the current zone that fails will automatically reroute to the child zones.

Sorry if I'm being dense - but how does this work when creating an instance ? I.e if there is no compute server in teh parent zone, how does a child zone get chosen ?

> 4. Yes, the project needs to live in all zones. Again, this will change with keystone integration.
So if I'm using VLANs, does this mean my instances in the same project (from teh parent zone perspective) will be on different VLANS ?

Is there a specific blueprint which covers how zones will work witrh Keysone ?

Thanks,
Claire

Revision history for this message
Sandy Walsh (sandy-walsh) said : 		#3

Not at all ...

2. The services (compute, network, volume) all report their status to the ZoneManagers in the Schedulers. When the Scheduler has to decide where to place an instance it consults the ZoneManager to determine where to place it (best fit). If there are no Compute services running in the current zone it delegates the request to each of the child zones. They, in turn, respond with a "weight" to place the instance in that Zone. The parent zone then selects the child zone with the lowest weight and forwards the "create instance" request to that zone.

4. possibly ... I'm sure exactly how the network implementations are utilizing the Zone architecture currently. Perhaps we need some input from the groups closer to that code.

I don't think the Keystone bp specifically talks about Zone integration, but the reason it was decided that Auth lives outside of a Nova deployment was to ensure project ID and resource owners could span Zones.

Can you help with this problem?

Provide an answer of your own, or ask Claire McDay for more information if necessary.

To post a message you must log in.