OCCI Openness (was Re: Enomaly, Inc. owns CloudCamp™ - has it jumped the shark?)

[Sam Johnston]

Alex,

Between trekking around Europe (on my own time and budget) to raise awareness of and gather feedback for the OGF's Open Cloud Computing Interface (OCCI) and my partner's recent surgery I've not yet had a chance to write a retort for your completely unnecessary and unjustified diatribe. Until now...

On Thu, May 28, 2009 at 11:00 PM, Alex Esterkin <aest...@gmail.com> wrote:

On Thu, May 28, 2009 at 10:04 AM, Sam Johnston <sa...@samj.net> wrote:
>

> Answering your other question, if you want to deliver immediate, tangible
> value to cloud interoperability then join the Open Cloud Computing
> Interface working group at http://www.occi-wg.org/.

This explains it all, Sam.

Explains what exactly? My discontent regarding the "ownership" of CloudCamp? How?

Remember the question was about "setting standards and establishing better practices" - walking rather than talking. The OCCI working group is IMO the best place to do that right now, especially since the CCIF group has reduced to idle (if at times useful) banter.

The Universal Amazon EC2 API Adapter (UEC2) was stillborn and the Unified Cloud Interface (UCI) appears to be down for the count (3 months and counting with little or no signs of life), DMTF votes cost $12k and good luck getting involved in the development of Amazon APIs without begging for a job there.

The Open Cloud Computing Interface working group mentioned in your
email is presently "coordinated" by 3 people: by you, Thijs Metsch
(who is a Software Engineer at Sun Microsystems, based in Germany),
and Alexis Richardson (who is Managing Director of Business
Development at CohesiveFT, based in Great Britain).

Aside from being irrelevant, this information is inaccurate - Ignacio Llorente (an academic from Spain) was recently called off to work on an EU cloud project and replaced by Intel's Andy Edmonds (representing SLA@SOI), Alexis Richardson is CEO of Rabbit Technologies and an active participant in the standardisation of AMQP, and I'm "just" the secretary (if also the most active participant).

I'm not sure what your point was but surely a standards effort driven by people like this and independents like myself will be far more open and fair than those driven by vendors with conflicting interests (FWIW I represent large enterprise users who will ultimately be consuming the API and have a strong interest but an absence of conflicts).

For such an
effort to be successful or even relevant, you need to be inclusive and
attract active participation of engineering and business experts as
well as research, non-profit, and for-profit organizations on a global
scale.

Last I checked we had over 150 participants on the list alone - and that's not including organisations providing us use cases and requirements, waiting to implement it as provider and/or consumer, giving one-on-one feedback, etc. Profiles range from individuals like myself to academics, existing providers and a range of potential users. I assure you that being inclusive is not our problem - the requisite religous wars are proof of that and there is nonetheless some truth in the observation that "Consensus is mostly good. Except when it is not" (where there lacks even a loose consensus someone needs to give direction).

I would argue that up until this point, the Open Cloud
Computing Interface working group activities have been very far from
transparent, far from open, and far from inclusive.

I'm sorry but this is complete and utter BS. Pretty much everything we do is on the occi-wg list, except perhaps for menial administrative tasks like writing press releases. The archives are open, anyone can join (with or without an OGF membership) and there is no moderation. The weekly conference calls are open too and anyone can join and contribute to the SourceForge project which contains the wiki.
 

Being a
Standards group under the OpenGrid Forum umbrella is a great
opportunity that you have not used.

Au contraire. We have already examined existing OGF work and have connections to and participation from a number of other working groups. OCCI was a highlight of the recent OGF 26 event in North Carolina, itself proving a great opportunity for us to interact with other members. Open to suggestions about how we can further benefit from this "great opportunity".

If you wanted to attract
interest and participation by posting at this forum, too bad - you may
have achieved the opposite.  In my opinion, your negativity and
flamings are incompatible with your role and activities as a open
standards community leader.

Yes, well we all know the value of free opinions now, don't we. If you'd like to provide useful feedback or even constructive criticism then I'm all ears, but attacking what is currently the only opportunity for us to benefit from a free and open standard for cloud infrastructure doesn't help anyone. Ironically virtually all of my "negativity and flamings" have been with a view to driving openness, transparency and inclusivity (with some success I might add).

I can't help but to notice you have made no attempt whatsoever to get involved, so unless you'd rather see us playing follow the leader for the foreseeable future (be that VMware via DMTF or Amazon with an "open" EC2) then I suggest you either do so or keep your unwanted opinions to yourself and let us get on with our work.

Thanks,

Sam

[eric]

>
> The Universal Amazon EC2 API Adapter (UEC2) was stillborn and the
> Unified Cloud Interface (UCI) appears to be down for the count (3
> months and counting with little or no signs of life), DMTF votes cost
> $12k and good luck getting involved in the development of Amazon APIs
> without begging for a job there.

This is the first I've taken notice of UEC2. This is pretty much
exactly what Annelidous is seeking to do, although the "frontend" won't
only be EC2, but other protocols (I.E. OCCI). Currently, we have our
own open exterior protocol, ACII, which is just an exposure of the
internal API on which other frontends would build.

The difference, I see in UEC2 and Annelidous, of course, is that the
latter actually exists as code. We took a real, working platform, and
opened it up. UEC2 is simply Ruv's attempt to "round up sponsors" and
put together a group of interested parties that might work on
crowd-sourcing a new project. From what I can tell, UEC2 never became
more than a thought experiment.

That all said, if anyone did find UEC2 an interesting/good idea, I do
encourage them to contact me about Annelidous -- we'd certainly like
your input, suggestions, and if possible, code!

--
Regards,
Eric Windisch

[Sam Johnston]

On Mon, Jun 8, 2009 at 6:22 PM, eric <er...@grokthis.net> wrote:

> The Universal Amazon EC2 API Adapter (UEC2) was stillborn and the
> Unified Cloud Interface (UCI) appears to be down for the count (3
> months and counting with little or no signs of life), DMTF votes cost
> $12k and good luck getting involved in the development of Amazon APIs
> without begging for a job there.

This is the first I've taken notice of UEC2.  This is pretty much
exactly what Annelidous is seeking to do, although the "frontend" won't
only be EC2, but other protocols (I.E. OCCI).  Currently, we have our
own open exterior protocol, ACII, which is just an exposure of the
internal API on which other frontends would build.

Although adapters like this may end up being a necessary part of the cloud computing landscape, they tend to be far from the path of least resistance - as you are confined by the functionality of the APIs on both sides you tend to end up with an impedence mismatch.

A good example of this is trying to match up RESTful/resource oriented APIs like OCCI with RPC-based APIs like Amazon EC2 - it's like trying to compare a functional programming language with an object-oriented language. To render even OCCI's simple descriptor language might require 1/2 a dozen EC2 calls and carry the associated performance hit. For a single resource that's fine but for collections you're toast and need to start thinking hard about caching and so on.

The inverse is also true - a small number of CRUD operations replace a large number of RPC calls. This is why I've abandoned trying to compare APIs on a function-by-function basis, moving instead to requirements in the form of a feature matrix.

Another difficulty is creating an API that is compatible with the different approaches taken by various implementors - some do not allow a machine to exist in the "stopped" state for example and if you "stop" a running machine you implicitly destroy it.

Will take a look at your ACII directly,

Sam

[Alex Esterkin]

On Mon, Jun 8, 2009 at 11:50 AM, Sam Johnston<sa...@samj.net> wrote:
> Alex,
>...............................................................................................
>...............................................................................................

>
> I can't help but to notice you have made no attempt whatsoever to get

> involved, so ...... I suggest you either do so or keep your unwanted opinions to yourself

> and let us get on with our work.
>
> Thanks,
>
> Sam
>

Very eloquently stated, indeed.

Alex

[Sam Johnston]

On Wed, Jun 10, 2009 at 6:14 AM, Alex Esterkin <aest...@gmail.com> wrote:

On Mon, Jun 8, 2009 at 11:50 AM, Sam Johnston<sa...@samj.net> wrote:

> I can't help but to notice you have made no attempt whatsoever to get

> involved, so ...... I suggest you either do so or keep your unwanted opinions to yourself

> and let us get on with our work.

Very eloquently stated, indeed.

Yes, well you know I'm one to say it how it is (or at least how I see it), and I'm sure you'll appreciate the irony in criticising a process for being closed without so much as attempting to get involved.

IOW, if you're serious in your desire for open cloud standards (something I am deeply passionate about and spend the vast majority of my time on these days) then prove it. If not, don't complain when we miss the opportunity and end up playing follow the leader.

Sam