[occi-wg] moving forward

Wed May 27 05:21:30 CDT 2009

The Process - Will it work? In a word, yes but let us make what we have worked on in the wiki [1] as the base for our comparison, compare/contrast.
On aspects of patents, IANAL etc but can we split that discussion into its own thread?

Regarding comparisons - I think that it is a very useful exercise to do such a comparison (I’m biased - I suggested it! :-D). However to Alexis' course suggestion I would like to add one amendment and place emphasis on taking what we, OCCI-WG, have in the wiki [1] and then compare/contrast it with others and see which is weak where and then provide recommendations to OCCI and/or the API provider. That way everyone gets something out of it and encourages participation.

Indeed on reviewing APIs for SLA at SOI [2][3], I might suggest that OCCI would need to manage long running tasks (such as provisioning of VMs) in a fashion not all too similar to how GoGrid do it. Also, reviewing the other models will help us form a common set of attributes for our nouns and help take as many different providers needs into consideration. Another example is SUN's API. It has a fixed static hierarchy of groupings (Cloud, VirtualDataCenter, Cluster) - those grouping may not suit every provider. So OCCI can make that more generic and provide a means to make group/collection management to suit all providers. Sun do support the use of tags something that we can consider in the our design. These are not proposals right now but a flavour of how we can proceed with the Process so let's not diverge this thread.

Sam and I and have clarified what we feel is a good starting point from the aspect of model and protocol - HTTP, RESTful (this will help in define the "WHAT" operations do) and always striving to adopt best practices, initially XML for representation (yes, attached to a schema). But wait, yes there are complimenting JSON and TXT renderings but as Thijs mentioned we can add/subtract in the future. Details of this can be found here [1]. With respect to Atom there are 2 points to deal with:

1) OCCI Model Independence
OCCI is not tightly coupled to Atom in any way. This relationship was unclear to me but by discussion with Sam this is now rectified. An OCCI model can exist without the dependency on Atom and a model-instance can be generated without referring to external schemas like Atom.

2) OCCI and the use and management of collections.
In reference to Atom: Currently there is no real standard approach in dealing with collections of item when it comes to web APIs - it's left up to application logic directed by each individual service provider. Atom provides a suggestion to this as part of its standard and, one could argue by association, a standard in itself. With this in mind it makes sense to provide a standardised means to interact and manage collections in a way that is common to all service providers and so we should as part of our API design use Atom's specifications on this. As OCCI we can either mandate this or recommend this but bear in mind that it's a means to further interoperability.
An interesting parallel on this was told by Alexis to me: One of the reasons that the adoption of OODBs hasn't been rapid is the problem whereby you need to create your own lookup scheme and collection management. For RMDBs this is a freebie and a standard (if you ignore extensions etc), however with OODBs there are a number of competing proposed suggested standards - and of course the "roll-your-own" variety.

Finally to echo Tim's point - let's get a consolidated direction & consensus on this to somewhere. I feel we're not far off.
I myself am available to chat to anyone (skype:andy.edmonds) or if you want my mobile, message me off-list.

Andy

[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/APIDesign
[2] http://forge.ogf.org/sf/go/doc15610
[3] http://forge.ogf.org/sf/go/doc15612

-----Original Message-----
From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On Behalf Of Alexis Richardson
Sent: 26 May 2009 22:31
To: occi-wg at ogf.org
Subject: [occi-wg] moving forward

Hi all,

I spoke with Thijs today who has been representing OCCI at the current
OGF meeting.  The feedback from OGF leadership is that they are
pleased with our progress and the level of participation.  But they
would also like us to move on from the deep discussions about formats,
a view with which I think *everyone* on the list agrees.  A lot has
been said about different approaches and we now risk repetition,
deviation and hesitation; which I for one do not want to see persist.
Now is the time to stake out areas where consensus exists - to try to
seek rallying points.  Where are those to be found?

I met with Sam, Roger from Fujitsu, and Chris and Richard from EH last
week and had a set of very interesting conversations.  I was left with
the feeling that the first task is to identify areas where there is
agreement, and from there establish consensus, from which basis a
course of action can be proposed.  I'd also like to thank Sam for his
thoughtful emails on HTTP from his own work after last week's
meetings.  These give me cause to believe we all want to converge.

On the other hand, and negatively, I feel that the level of
participation while high has devolved into a few people talking.  No
matter what the quality of any individual's input, this is NOT the
activity the chairs want to see.  We want input from others.  And we
want to hear more from at least two kinds of people:

* People with cloud implementation experience who want to implement
OCCI.  We need more than one prototype implementation for this process
to be useful.  It will NOT help us to create an OCCI that nobody wants
to implement.  Let's bring the implementers into the fold more, both
open source software people and service providers.

* End users who represent real world cases especially from, e.g.
enterprises.  We don't want to build a castle in the sky and we must
look to our requirements to bring us down to earth.  Requirements are
necessary to move us forward from prior art to the standard.  Let's
bring more real world requirements to OCCI and make this thing really
concrete.

So: We all need to reach out to people that we know who can join the
conversation.  If we have enough of them, we can get enough meaningful
participation from implementers and requirements advocates, to hammer
out something really plausible.  PLEASE can everyone do that - reach
out to people.

I personally think we have something to show people: we have done good
work on the state model, as a group, and Andy et al., have worked on
formalising and tidying it up.  This is great - but not enough to
achieve consensus on the next steps.

So, what have we not done yet?

We have not focussed on the semantics of RESTful interactions with the
cloud - the actual API and interop definitions.  I have not seen clear
statement of requirements here, rather I fear we have let ourselves
get sidetracked by too much talk about HOW the OCCI operations might
be expressed, which may impact integration, and not enough about WHAT
they do (which is critical for defining behavioural semantics).  By
the same token (no pun intended), by concerning ourselves with one
metamodel style over another, we risk coming to the actual
interoperable behavioural protocol as an afterthought.  Let's not do
that.

Because we want to make use of prior art, at this point I am going to
quote Andy's email from earlier today: "If we want to take the middle
ground yet not sit on the fence it would be a useful exercise to see
what [ GoGrid ] and [ Sun ] offer and do not offer? See where our
efforts here could improve these published APIs and models?"

I think this is so eminently sensible that I am going to PROPOSE A
COURSE OF ACTION.  Please - everyone - this is my view as one of the
three chairs, but I want to appeal to you - is this a plan around
which we can proceed - is there consensus here?

A) Take the Sun and GoGrid models (and use cases) and see what they
offer.  These meet the criteria of being open and based on reality.
Recall the comparison matrix here:
http://spreadsheets.google.com/ccc?key=pGccO5mv6yH8Y4wV1ZAJrbQ

B) Because the Sun API provides a RESTful picture of a data center, I
suggest we first ask: how can the GoGrid model improve it?  At the
same time ask: how can the OCCI state model improve it?  I'd love to
see Andy help us shape this discussion and bring some of the OGF
community to bear on the problem - especially the *formal* end of
making a clear spec that can facilitate interop.

C) With these basics done, let's build from the base we will have
created.  What requirements do Sun/GoGrid/OCCI not meet?  What changes
or extensions are needed?  This is where I think we really want to
hear from people like Sam (eg
atom/links/documents/collections/caching) and from cloud providers eg
Richard and Chris from EH, and from the enterprise BigCo people.

D) Show this work to the people on the list and people watching the
conversation.  Is this implementable - and are enough people willing
to have a crack at implementing a prototype or several prototypes?  If
so then I would suggest that - at that time - we had reached an OCCI
0.9 draft.  Here, Thijs is (a) acting as a liaison point with the
other standards bodies like DMTF, and (b) looking at Extension points
and alternative renderings.

What do people think?  Speak out here.  Invite people to the list to
join this process and they can speak out.  Tell people - will this
process work?

alexis
_______________________________________________
occi-wg mailing list
occi-wg at ogf.org
http://www.ogf.org/mailman/listinfo/occi-wg
-------------------------------------------------------------
Intel Ireland Limited (Branch)
Collinstown Industrial Park, Leixlip, County Kildare, Ireland
Registered Number: E902934

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.