Nouns

These are basic resources upon which the cloud API operates.

• Compute/Servers/Workloads (e.g. VDI workloads are clients)
• Storage
• Networks

Nouns are linked together to denote when a server uses storage or network resources. These links may themselves have attributes.

Suggestion: what about collections? For example

• a group of storage servers is a pool
• a group of compute nodes is a cluster
• a group of clusters is a data centre

A model of these nouns relationships (and their attributes) could be as follows:

Although this model could in itself a metamodel, it could extend atom to express the relationships between nouns as depicted in the above diagram. Using this metamodel we can express an OCCI model using the described nouns and attributes below. For example:

This model has been implemented in XSD occi.xsd and an example model instance rendering in XML can be found in occi-instance.xml . This was generated by the Java code here OCCITest.java. The eclipse project and all dependencies used to create the XML instance rendering can be downloaded: OCCIModel-eclipse-project.zip.

Verbs

These are operations acting upon the nouns. The create, read, update and destroy verbs are present for all nouns, but other verbs may also be available. We describe the create, read, update and destroy verbs explicitly in each case, as their exact behaviour needs to be properly specified.

Verbs acting upon servers

• Create (includes start if only running servers are supported)
• Read
• Update
• Destroy (includes hard stop without ACPI signal if running)

• Start (optional)
• Stop (optional; hard stop without ACPI signal)
• Shutdown (send ACPI signal)
• Reset (send ACPI signal)

Semantic issues

We need to be able to support providers who only have a concept of a running server (like EC2, ElasticHosts) and providers who have a concept of a stopped server (like GoGrid).

If you don't have stopped servers, by definition 'create' must result in a running server, and 'shutdown' must eventually result in implicit destruction. However, providers with a concept of stopped servers may want to expose an ability to create them in a stopped state, and won't want all servers to be destroyed when they are shutdown. We need to provide a way to express these behaviours, and an opportunity for a provider to refuse if a behaviour they don't support is requested. One way to do this would be for create to take an attribute 'status' expressing the desired state of the server following creation, and an attribute 'persistent' recording whether the server should be maintained in a stopped state or auto-destroyed when it is shutdown.

Other suggestions:

• Suspend?
• Clone?

Do these naturally belong as extensions?

Verbs acting upon drives

• Create
• Read
• Update
• Destroy

There are two variants of read and update/write required: one of which affects the attributes of the drive, and one of which reads and writes from the actual block device itself, hence we might add the verbs:

• Read
• Write
• Image

Resize of block device can be implemented as an update of a size attribute, or via a separate verb. The size attribute will presumably be exposed for reading, so also allowing it to be updated is perhaps the most natural choice, and it might be treated as a read-only attribute for providers who do not allow drives to be resized.

Other suggestions:

• Copy (aka clone aka snapshot, creates a new drive which is a copy of an existing one)

Verbs acting upon networks

• Create
• Destroy
• Read
• Update

Networking discussions still very preliminary. Need at least verbs to allocate and deallocate static IPs available to a customer on the public internet network.

Attributes of nouns

These are the specific properties of a server, drive or network. For instance, a drive has an associated size in bytes.

Attributes of servers

• title
• summary
• architecture
• cpu cores
• cpu speed/bandwidth (vendor-specific priority versus other virtual servers on the same host)
• memory/ram
• status (optional): active, stopped, starting, suspended
• persistent: should server be auto-destroy when it shuts down, or move into stopped state

There will definitely be vendor-specific attributes in every case for server configuration. (For instance, ElasticHosts would want to expose VNC configuration for console access.)

In addition, nouns are linked together to denote when a server uses storage or network resources (see below).

Attributes of drives

• title
• summary
• size

Other suggestions:

• status (optional): active, inactive
• imaging: or similar progress indicators for any verbs which start background operations
• claimed/mounted: whether drive is in use, and if so by which servers
• claimtype/mounttype: is the drive allowed to be mounted by multiple servers simultaneously
• persistent (should the drive be auto-destroyed when its server exits, c.f. Amazon AMI storage)
• writable: "golden master" drives can be set read-only
• occupied space (for thin provisioning; for thick drives occupied == size)
• reserved space (for thin provisioning; for thick drives reserved == size): this attribute is read/write

Attributes of networks

• name
• IPs available (at least to show static IPs available to customer on public internet network)

Attributes of links

Nouns are linked together to denote when a server uses storage or network resources. These links may themselves have attributes, for example:

• title
• interface: specifies how the server is attached to the other resource (e.g. ide:0:0, scsi:0:0, etc. for storage or nic:0 for a network)

Attachments:

occi.xsd [NounsVerbsAndAttributes/occi.xsd] OCCIModel-eclipse-project.zip [NounsVerbsAndAttributes/OCCIModel-eclipse-project.zip] OCCITest.java [NounsVerbsAndAttributes/OCCITest.java] occi-instance.xml [NounsVerbsAndAttributes/occi-instance.xml] modelWithAndreComment.png [NounsVerbsAndAttributes/modelWithAndreComment.png] model.png [NounsVerbsAndAttributes/model.png] mmodel1.png [NounsVerbsAndAttributes/mmodel1.png]