Ideas for Regions

Regions in boto are kind of a pain in the ass at the moment.

The first problem is that region-related code is spread all over the place. There is a regioninfo.py in boto but there are also regioninfo.py modules in ec2, rds, sdb, and sqs. Also, each module (e.g. ec2) has a regions function which returns all of the regions for that service, a connect_to_region function that takes a region_name and returns a connection to the service in that region and, except for ec2, a hardcoded list of region names and endpoints. That means that adding a new region requires editing a bunch of files and there is a good chance of missing something or making errors.

Another problem is that since the Connection class constructors and the connect_* methods in the boto module expect RegionInfo parameters rather than region_names, it forces users to construct a RegionInfo data structure just for the purpose of creating the connection or to use one of the other methods like connect_to_region but those are all contained in the service modules (e.g. boto.rds) rather than at the top level. There are just too many ways to get a connection right now. It's confusing for users and it's confusing when writing documentation, as well.

Goals

1. Provide a single, unified method for creating a connection to a particular service in a particular region.
2. Hide the details of RegionInfo from users of boto.
3. Make it easy or at least easier to add new regions and endpoints.
4. Make sure we provide a way to support non-AWS services like Eucalyptus, Openstack, etc.
5. Clean up the code base.

Idea #1

We would simply modify the current boto.connect_* function to accept either a RegionInfo object OR a string for the region parameter. If a string is passed in we would assume it was the name of a region (e.g. "us-east-1") and we would then call the corresponding connect_to_region function already in the service module.

From a user's perspective, you would do this:

>>> import boto
>>> boto.connect_ec2(region='eu-west-1')

We would change all tutorials and documentation to point people in this direction and discourage the use of any other methods of creating a connection. All of the existing code would remain as is.

This is the lowest impact approach. It helps with goals #1, and #2 but doesn't do much for the other goals.

Idea #2

Create a boto.regions module. This module would contain all region-related functions and classes. It would provide a function like this:

def connect(service_name, region_name, **kwargs)

Where service_name would be a string representing the service you want to connect with (e.g. 'ec2', 's3', etc.) and region_name would be interpreted as above. This method would then return the appropriate connection object.

Within this module, we could embed the knowledge of how to map a service name and region name to an AWS endpoint so most or all of the hardcoded references could be removed although we would probably still want to have some static data structure that contained the names of the currently supported regions.

We would then modify the connect_* methods in the boto module to make the appropriate call to the connect method described above.