OpenStack Nova EC2 API Flow

I recently decided to poke around with the OpenStack Nova EC2 API implementation in order to have a go at bug 855663. I hadn’t looked inside nova-api before, so had some reading to do in order to figure out the flow. Specifically how a request is routed to the method that implements that feature. There are two prerequisites for understanding this, WSGI and paste deploy.

WSGI (Web Server Gateway Interface) is a standard (pep 333) that defines the interface between a web sever and a web application. Nova uses the WSGI server from eventlet (eventlet.wsgi.server).

Middlware in WSGI is an application that implements both sides of the spec. It behaves like an application to its container, and behaves like a server to the application it contains.

Paste deploy is used to to create composite applications from chains of middleware, with an application on the end. The full nova paste configuration file is here. I will be following the keystone pipeline, shown below in a snippet of the paste config:

[composite:ec2]
use = egg:Paste#urlmap
/services/Cloud: ec2cloud

[composite:ec2cloud]
use = call:nova.api.auth:pipeline_factory
noauth = ec2faultwrap logrequest ec2noauth cloudrequest validator ec2executor
keystone = ec2faultwrap logrequest ec2keystoneauth cloudrequest validator ec2executor

In the keystone pipeline, all the items are middleware apart from ec2executor which is an application.

I created the following flowchart in an attempt to trace a request through nova-api.  As I said above, I am new to the nova code, so I’ve probably made mistakes! Corrections appreciated in the comments.

NovaEC2APIRequestFlowchart (2)

I haven’t shown it here, but the nova S3 service (nova.objectstore.s3server.S3Application) doesn’t use an paste deploy ini file, instead it subclasses nova.wsgi.Router and defines URL mappings explicitly in its constructor. This is easier to read (in my opinion) but less flexible than the .ini approach.