openstack: Clarify zone vs. availability zone vs. region

[meteorfox]

There's seems to be confusion on terminology in the OpenStack provider implementation for what a zone stands for in PKB, and what a zone means for OpenStack.

The following issues/PRs have been opened due to this confusion and trying to address it.

734 Expose availability zone for VM

769 Multi-region support

770 Expose region name (All services) *workaround

773 Expose availability zone for Volumes services

The root of the problem is that --zones flag value is being used as an OpenStack availability zone, where PKB actually intended the flag to mean what in OpenStack terms is called a region.

As of now, OpenStack provider implementation uses the --zones flags as an availability zone for all services (Nova, Cinder, Swift, etc). PRs #734 and #770 tried to work around some of the problems caused by this but is not directly solving the problem.

I want to use this issue to track the work to fix this properly.

Here's what I have in mind as of now:

Tasks

• - Use --zones flag's value only to represent an OpenStack region
• + Introduce --region flag for specifying OpenStack region to use
• + Use --zones flag for specifying default availability zone
• Use optional OpenStack provider-specific flags to override which availability zones will be used for each core service that supports it (e.g. Nova, Cinder, Swift, Neutron, etc)

In summary, after this issue is properly solved one should be able to use something like the following:

./pkb.py --cloud=OpenStack --region=RegionOne \   # Addresses PR #770
         --machine_type=m1.medium --image=Ubuntu \
         --openstack_public_network=public --openstack_private_network=service \
         --openstack_nova_zone=myzone1:711465-compute007 \  # Addresses PR #734
         --openstack_neutron_zone=myzone1 \
         --openstack_cinder_zone=myzone2 \  # Addresses PR #773
         --openstack_swift_zone=myzone2 \
         --benchmarks=ping

[meteorfox]

@kivio What do you think?

[voellm]

Optionally we can have OpenStack not support the --zone flag and add a --region flag. Some providers like AWS would benefit from a "region" as an option as well.

[meteorfox]

@voellm That's an option as well, I believe that it will require a tiny bit more work since most of the providers (at least AWS, and Rackspace) make the assumption that zone either contains, or actually is, the region. But yes, having a distinction between --region and --zone would be much cleaner.

I can start with OpenStack, it should be pretty simple.

[meteorfox]

@voellm Do you want me to make --region an attribute of the virtual_machine.BaseVirtualMachine class, or should I just declare it within the openstack module for now? I prefer the latter, and leave the attribute 'promotion' for another patch along with the changes to the providers that make use of it.

[voellm]

I'd define it next to the --zone flag in pkb.py here - https://github.com/GoogleCloudPlatform/PerfKitBenchmarker/blob/master/perfkitbenchmarker/pkb.py#L105

The default should be "None". This will allow providers like AWS to use zone inference like this code here - https://github.com/GoogleCloudPlatform/PerfKitBenchmarker/blob/master/perfkitbenchmarker/providers/aws/aws_virtual_machine.py#L118

[lwatta]

The zone thing is hitting us. We use AZ's for nova but not yet for cinder and other services so we have a mix. Your proposed fix in the first post would fix our issues. Right now we've modified the code for cinder to simply use the default zone.

[kivio]

@meteorfox for me your proposition sounds really good :) i can help with codding ;)