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

[Sam Johnston]

On Fri, Apr 17, 2009 at 10:32 AM, Richard Davies <
richard.davies at elastichosts.com> wrote:

> You may be overestimating how much is in the database (in our case at
> least!). To avoid any risk of inconsistency, we typically don't cache any
> server attributes on the central management servers where these are best
> mastered on the virtualization hosts themselves. That includes things like
> server titles, memory sizes, etc, etc. Pretty much just the UUIDs and which
> hosts they're on is permanently remembered centrally.
>

This is an interesting point even if it's already starting to get down to
implementation details. There's little interest in a client retrieving a
list of bare UUIDs, except as a precursor to iterating through them
individually and requesting more information (which sounds like a source of
more significant performance problems to me, expecially for remote
infrastructure). Nonetheless we should try to avoid such expensive calls
(e.g. querying every server)... or at least allow them to be completed in an
inexpensive way.

If I were to write a client today I would probably start by asking for
categories with which to build a top level tree view. Clicking on that would
result in a category search (e.g. http://example.com/-/category) and I'd ask
for relevant details such as running state (e.g. starting, started, stopped,
etc.) which I would use to select icons etc. Bringing up a property page
would result in a retrieval of all the relevant details for a single UUID.

Overall I think that giving the ability to specify which non-core extensions
are queried solves most of the problem. Another optimisation might be to
have extensions return "cheap" information (such as the rate, currency,
etc.) while saving really expensive operations (such as totalling billing
logs) for single-resource calls.

Thanks for drawing attention to this need Richard - great feedback!

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