Afternoon all,
Over the last few weeks I've been busy evangelising OCCI at various cloud
computing events througout Europe:
- Cloud Computing Expo - Prague (18, 19 May 2009)
- Cloud Computing Expo - London (20, 21 May 2009)
- Cloud Views Conference - Porto (28, 29 May 2009)
In addition to doing the Introduction to the Open Cloud Computing Interface
(OCCI) <http://docs.google.com/Presentation?id=ddqm27m2_298fsf9mqdg>presentation
I had the opportunity to sit on panels at the events and to
introduce "Interoperability" as the topic for Cloud Views 2010. It was great
to meet many of you and to have various opportunities to discuss (often at
length) the API - some great feedback was given and good progress made on
working towards consensus. We've found ways to evict Atom from individual
resources and adopt a simple key/value descriptor format for a start which
should make some of you very happy.
I also spent 90 minutes running through and discussing OCCI with the SNIA
Cloud TWG at their last meeting (last week) which I think is a great
opportunity for us to ensure that our respective standards are at least
somewhat compatible and avoid a rerun of WS-* (I would hope for example that
we can use an SNIA descriptor format to define non-trivial storage
resources). Thijs is busy formalising this arrangement and a similar one
with the DMTF and I encourage those of you who are interested in these
projects to join them so we can get some cross-pollination going on
(especially those of you employed by member companies - neither group is as
open as we are).
Anyway I'm back this week after my partner's surgery and between looking
after her while she recovers over the course of the month I'm hoping we can
make some good progress quickly. It's in all of our interests to deliver
while we still have an opportunity to be relevant as the last thing we want
is to end up playing follow the leader (regardless of whether the leader
happens to be VMware via DMTF or Amazon with an "open" EC2).
Cheers,
Sam
Hi guys,
It is again time for our weekly concall. This time I think their is a
lot to discuss. First of all OGF26 is over and after some weeks of
discussions with several people I think it is necessary to get back on
track, and get some lively discussions back :-)
Therefore the current agenda looks like:
1. Short announcement from the chairs
2. Update on the progress of the last weeks
2. Requirements and Use cases
3. API discussion
If you want more topics and discussions please add your topics:
http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Concall20090…
So please take some time and join the discussion. The concall data is
located here:
http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Teleconferen…
The concall starts at at 5pm CET, 08am PDT, 11am EDT, 4pm BST. For your
timezone information - have a look at the wiki :-)
All the best,
-Thijs
--
Thijs Metsch Tel: +49 (0)941 3075-122 (x60122)
http://blogs.sun.com/intheclouds
Software Engineer Grid Computing
Sun Microsystems GmbH
Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com
D-93049 Regensburg http://www.sun.com
FYI, some pertinent discussion about HTTP from another list.
---------- Forwarded message ----------
From: Sam Johnston <samj(a)samj.net>
Date: Wed, Jun 3, 2009 at 3:38 PM
Subject: Re: HTTP is Dead, Long Live The Realtime Cloud
To: cloudforum(a)googlegroups.com
On Wed, Jun 3, 2009 at 3:04 PM, Gregg Wonderly <greggwon(a)gmail.com> wrote:
> HTTP is not really the power point of web delivery. AJAX, HTML, CSS, DHTML
> etc standards are what make it powerful. REST is a useful architectural
> model, and application protocols on top of HTTP can still extend the model
> to provide more powerful application APIs that will simplify development of
> advanced web delivered applications.
Pretty much everything (useful) is built on top of HTTP and if anything the
lesson we should learn from previous attempts to deviate from it (SOAP,
XML-RPC and WS-*) is that we should in fact be embracing it and getting as
close to it as possible.
Earlier (in the context of OCCI development) I asked Is AtomPub already the
HTTP of cloud computing?<http://samj.net/2009/05/is-atompub-already-http-of-cloud.html>,
figuring that it delivered the out-of-band "Web Linking" that HTTP couldn't
(traditional web linking is in-band, through use of HTML's "A" and "LINK"
elements, but that doesn't work for non-HTML payloads like OVF, ODF, etc.).
There was (unfortunately) huge backlash from the XML-xenophobes (I say
unfortunately because the RealCloud™ players, most notably Google and
Microsoft, have adopted it strategically for pretty much everything they're
doing in the space) so it has been dropped at least for the time being from
individual resources (even if it remains for collections, ironically
increasing complexity by requiring two different approaches depending on
cardinality).
Anyway if you ignore the problem of collections (which can be passed either
by reference as a plain text list of links, or by value with a meta-model
like Atom - with O(n+1) and O(1) performance respectively) then it turns out
HTTP actually provides for web linking in the earlier drafts, by way of the
Link: HTTP header and the LINK and UNLINK HTTP verbs. Obviously the guys
responsible for writing this stuff could see further into the future than
the guys implementing it!
The point is that using native HTTP it is possible to create an extremely
RESTful, scalable and trivial to use "Resource Oriented Architecture (ROA)"
that "just makes sense" - every resource has a URL and can be retrieved in
various representations (e.g. a DOC could also be retrieved as PDF, a song
as MP3 or AAC and a virtual machine as OVF or a PNG screenshot), operations
can be repeated without fear of repurcussions, everything can be cached,
associations can be created between resources (e.g. a compute resource
having a link to storage and network resources), etc. This is far easier to
understand and write to than an RPC-based approach often associated with
SOA.
As for Wave, there's even a "HTTP PATCH" method currently being
reincarnated<http://tools.ietf.org/html/draft-dusseault-http-patch-14>that
allows you to make specific changes to a document rather than
replacing
it altogether with a PUT.
In summary, HTTP is far more powerful than you might think and given the
enormous amount of infrastructure and optimisation built around it you would
want to have one hell of a good reason to deviate from it. For Google having
an existing XMPP infrastructure (Google Talk) is strong incentive, but that
doesn't make it the best approach for the rest of us - work being done
around browsers becoming servers is also potentially applicable.
Sam
Hi guys,
In 1h and 10 minutes it is time for our weekly concall. My apologies for
the late invitation. I do not have and topics for the agenda.
If you have some please add the to our wiki page:
http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Concall20090…
Either way I will open the line and see who joins.
Please find the dialin details as usual at:
http://forge.ogf.org/sf/go/wiki2128
All the best,
-Thijs
--
Thijs Metsch Tel: +49 (0)941 3075-122 (x60122)
http://blogs.sun.com/intheclouds
Software Engineer Grid Computing
Sun Microsystems GmbH
Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com
D-93049 Regensburg http://www.sun.com
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
