[occi-wg] Semantics of OCCI API: nouns and verbs

[Richard Davies]

A few more detailed comments to flesh out Chris' overview:

> drives - block devices to attach to virtual machines. The general case
> here is clearly behaviour like Amazon EBS - drives are persistent and
> exist independently of virtual machines. A virtual machine can mount
> several drives, and conversely a drive (like a CD image) can in principle
> be mounted from several virtual machines. GoGrid 'one drive per server'
> behaviour is clearly a subset of this, and Amazon's filesystem initialised
> from an AMI at boot can be represented by throwaway copies of a drive (or
> copy-on-write) instead of writing back to the drive.

The variants which we see today are:

Amazon EC2 root filesystem
  - one drive per server, not exposed separately in API
  - non-persistent, initialized at boot from template (AMI)
  - single filesystem
  - does not include OS kernel or boot loader

Amazon EBS
  - any number of drives per server, exposed separately in API
  - persistent across reboots and server deletion
  - block device which can be partitioned into multiple filesystems
  - does not include OS kernel or boot loader, since a secondary drive

GoGrid
  - one drive per server, not exposed separately in API
  - persistent across reboots, but not server deletion
  - block device which can be partitioned into multiple filesystems
  - includes OS kernel and boot loader

ElasticHosts
  - any number of drives per server, exposed separately in API
  - persistent across reboots and server deletion
  - block device which can be partitioned into multiple filesystems
  - includes OS kernel and boot loader


We suggest taking the most general approach in the standard:
  - any number of drivers per server, exposed as first-class API objects
  - persistent across reboots and server deletion
  - AMI-like templates implemented as imaging/duplicating one drive from
    another
  - block device which can be partitioned into multiple filesystems
    (just like a hard disk)
  - includes OS kernel and boot block (just like a hard disk)


> guests - virtual servers booted from and accessing drives. Our guests
> exist as objects only when they are running, similar to Amazon's
> instances, but it may be more general to allow guests in stopped and
> suspended states in addition, as GoGrid currently do.

The variants which we see today are:

EC2 instances and ElasticHosts servers (as seen from the API) are ephemeral
and no longer exist once they are stopped. GoGrid servers persist in a
stopped state, and can be restarted from that state.

We suggest taking the more general approach in the standard:

Servers would include non-running servers in the same way as GoGrid. Perhaps
whether a server persists or not when it is shut down is an option when
creating a server?


> guests
>   create (takes simple description, e.g. including attached drives and
>           network interfaces)

It's worth commenting here on the granularity of VM specification. Both
GoGrid servers and EC2 instances are available in a small number of
fixed sizes, whereas ElasticHosts servers are continuously variable in CPU
and RAM, and our drives are continuously variable in size.

Again, taking the more general approach, we suggest that servers should be
specified in terms of continuous quantities of CPU, RAM and disk, with a
provider 'rounding up' to the nearest available specification if their
granularity is coarser than the standard API.