OldDocumentation

Who's who?

The general approach for processing a request is as follows:

• An RPC receives the request and processes the input and looks up Adapters in the AdapterRegistry.
• The AdapterRegistry can return a list of Adapters which support certain contracts regarding RPC calls.
• The Adapter then translates between the resource management and the (e.g. translating to XML). The AdapterRegistry is the only instance which knows about the concrete shape of a Resource and the formats a RPC wants.
• When adapting the RPC request, the Adapter asks the ResourceManagerRegistry for ResourceManagers which support the resource type which is asked for.
• The ResourceManager is a "database" for Resources, so you can call find, and reserve on it.
• Finally, the Resource is concerned about the concrete handling of resources (e.g. starting, keeping allocation times).

You may ask, why so many indirections? Here is why: The RPC shall only deal with communication layer stuff and the ResourceManager should offer a decent API which resembles requirements of this concrete resource type. The actual Resource then should know how the concrete resource needs to be handled. And finally to have ResourceManagers and RPCs work together we need a translator: Adapter. Consider the following example:

There is a GENI v2 RPC and an OFELIA RPC.
The VMResourceManager can handle XENResources and LinuxContainerResources, because their functionality is basically the same if you look from above (so no need to duplicate the code for it).
And then the VM-GENI Adapter and VM-OFELIA Adapter translate the RPC specific stuff, like parsing XML or fulfilling other contracts like "GENI calls start on reservation of a resource."

Ah, by the way, each plugin is supposed to handle their own persistency and configuration should be done via the config plugin.

What else do I need to know?

Notification is done via signaling and as with all plugins, the documentation should live in notification/plugin.py