This Page

Psst... hey. You're reading the latest content, but it might be out of sync with code. You can read Nova 2011.1 docs or all OpenStack docs too.

The nova.objectstore.s3server Module

Implementation of an S3-like storage server based on local files.

Useful to test features that will eventually run on S3, or if you want to run something locally that was once running on S3.

We don’t support all the features of S3, but it does work with the standard S3 client for the most basic semantics. To use the standard S3 client with this module:

c = S3.AWSAuthConnection(“”, “”, server=”localhost”, port=8888,
is_secure=False)

c.create_bucket(“mybucket”) c.put(“mybucket”, “mykey”, “a value”) print c.get(“mybucket”, “mykey”).body

class nova.objectstore.s3server.BaseRequestHandler(application)

Bases: nova.wsgi.Controller

Base class emulating Tornado’s web framework pattern in WSGI.

This is a direct port of Tornado’s implementation, so some key decisions about how the code interacts have already been chosen.

The two most common ways of designing web frameworks can be classified as async object-oriented and sync functional.

Tornado’s is on the OO side because a response is built up in and using the shared state of an object and one of the object’s methods will eventually trigger the “finishing” of the response asynchronously.

Most WSGI stuff is in the functional side, we pass a request object to every call down a chain and the eventual return value will be a response.

Part of the function of the routing code in S3Application as well as the code in BaseRequestHandler’s __call__ method is to merge those two styles together enough that the Tornado code can work without extensive modifications.

To do that it needs to give the Tornado-style code clean objects that it can modify the state of for each request that is processed, so we use a very simple factory lambda to create new state for each request, that’s the stuff in the router, and when we let the Tornado code modify that object to handle the request, then we return the response it generated. This wouldn’t work the same if Tornado was being more async’y and doing other callbacks throughout the process, but since Tornado is being relatively simple here we can be satisfied that the response will be complete by the end of the get/post method.

finish(body='')
get_argument(arg, default)
invalid(**kwargs)
render_xml(value)
set_header(header, value)
set_status(status_code)
class nova.objectstore.s3server.BucketHandler(application)

Bases: nova.objectstore.s3server.BaseRequestHandler

delete(bucket_name)
get(bucket_name)
put(bucket_name)
class nova.objectstore.s3server.ObjectHandler(application)

Bases: nova.objectstore.s3server.BaseRequestHandler

delete(bucket, object_name)
get(bucket, object_name)
put(bucket, object_name)
class nova.objectstore.s3server.RootHandler(application)

Bases: nova.objectstore.s3server.BaseRequestHandler

get()
class nova.objectstore.s3server.S3Application(root_directory, bucket_depth=0, mapper=None)

Bases: nova.wsgi.Router

Implementation of an S3-like storage server based on local files.

If bucket depth is given, we break files up into multiple directories to prevent hitting file system limits for number of files in each directories. 1 means one level of directories, 2 means 2, etc.