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

[Alexis Richardson]

Richard, Chris,

Thank-you both very much for this contribution!

Patrick Kerpan from CohesiveFT has kindly created a spreadsheet on
google that is intended for public consumption, that summarises the
API calls from known cloud provider APIs, in a matrix format.  I hope
to be able to share a link to that with this group shortly.  It is not
a substitute for work to create the OCCI API.  Instead, it forms an
important reference point for checking OCCI operations against current
providers.

alexis


On Thu, Apr 16, 2009 at 10:55 AM, Richard Davies
<richard.davies at elastichosts.com> wrote:
> 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.
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>