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

[Sam Johnston]

On Thu, Apr 16, 2009 at 11:55 AM, Richard Davies <
richard.davies at elastichosts.com> wrote:

>
> The variants which we see today are:
> <snip>
>
> 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


Agreed we should support all possible configurations including zero or more
storage resources (e.g. caters for netboot) and zero or more network
resources (e.g. caters for offline batch jobs). Not sure about the need for
the resources to be appearing as "first-class API objects" (that is, being
burnt into urls etc.) though.


> - persistent across reboots and server deletion


If a machine is stopped it would be up to the implementation to decide
whether it remains visible in a "stopped" state (e.g. persistent) or whether
it vanishes from view (e.g. ephemeral). I'm not sure what I make of machines
that can't be stopped (seems just like normal hosting because you can't stop
using the service without dropping your bundle).


> - AMI-like templates implemented as imaging/duplicating one drive from
>    another


Sure, I had planned to expose templates as machines that cannot be started,
only cloned. Same could apply to public storage devices (e.g. appliances)
and private storage devices (e.g. SOE images).


> - block device which can be partitioned into multiple filesystems
>    (just like a hard disk)


Sure, but sounds like we're getting down to the nitty gritty - there's an
argument for the block devices themselves being opaque and I'd almost rather
steer clear of details like MBR vs GPT.


> - includes OS kernel and boot block (just like a hard disk)
>

See above re: opaque block devices, though Amazon's separation of AKI
(kernel images), ARI (ramdisk images) and AMI (machine images) is something
we'll probably want to look at supporting if we expect them to implement it
and/or if we ever want to see an adapter.


> > 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?
>

I think it's more often than not a capability dictated by the service
provider. Where workloads are only ephemeral there's no choice but for them
to vanish when stopped. Where workloads are persistent I don't see a problem
with having a two-phase "stop" and "destroy" step, or exposing a "destroy"
actuator for a running instance and having the "stop" being implicit. I
think that makes more sense - these decisions are more useful at end-of-life
than start-of-life (what if I change my mind?). Perhaps the default could be
an optional parameter or somesuch.


> > 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.
>

Right, this is an important point. Basically I was thinking that you could
grab a template, set your values to suit, and POST it to the API. This could
be simplified for dumb clients by exposing a "clone", "deploy" or
"instantiate" actuator that would return the handle of the running machine.
Optionally specifying min and max instances ala Amazon should probably be
supported (nobody wants to do 1,000 "clone" calls now, do they - performance
is important for this API too).

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.
>

I'm not sure about rounding up as such - feels a bit messy (exceed the limit
by 1 byte and your cost will double for example). If the provider has
templates these should be advertised but ultimately it's up to the
implementor to decide whether to reject a request for an unsupported
configuration with an error or whether to satisfy it anyway with a larger
device.

I think the key thing for most of these points is giving implementors
flexibility without sacrificing interoperability, and fortunately I think we
can have our cake and eat it here.

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090416/479657a2/attachment.html