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

[Tino Vazquez]

Hi everyone,

I completely agree with Sam. We had a similar design challenge when
building OpenNebula API, we gathered that offering a call for
retrieving all IDs for any set of resources (physical servers and VMs)
will be very expensive and will have an impact pauperizing the
performance of OpenNebula's cache.

BUT, we also found out that many people demanded such feature. If we
are going to define such call (querying every server), I vouch for a
minimalistic approach (e.g. returning just the UUID and some ID string
maybe).

We will then have to figure out a way to give such information in a
way that doesn't impact (too much) on performance.

Regards,

-Tino

P.D.: Very nice list indeed

On Fri, Apr 17, 2009 at 10:54 AM, Sam Johnston <samj at samj.net> wrote:
> 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
>
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
>



-- 
Constantino Vázquez, Grid Technology Engineer/Researcher:
http://www.dsa-research.org/tinova
DSA Research Group: http://dsa-research.org
Globus GridWay Metascheduler: http://www.GridWay.org
OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org