Open Stack

2011/7/8 Jorge Williams <jorge.williams at rackspace.com>:
> I'm with Ewan on this point:   One of the nice thing about having a contract is that it clearly designates what's a bug and what isn't.  If the spec says the ID is a string and the client assumes it's an integer, then the client is at fault.  End of story.  It would be a different issue if the contract didn't specify what an ID was or if the contract only allowed for integers.

Answer me this: If the spec says a particular method was called Foo,
but EC2 actually calls it Bar and every client on the planet calls it
Bar, would you still insist on following the spec and ignoring what
the clients do?

Also, if the spec said that two arguments to a method needed to be
passed in one order, but they actually needed to be passed the other
way around and every single  client on the planet had figured this out
and followed what EC2 *actually* does rather than what it says in the
spec would you insist on following the spec? What good could that
possibly serve?

The EC2 API isn't a published, open standard with many implementations
of both server and client. What EC2 *actually* does is the real spec.
And what the clients *actually* expect is what we need to deliver. We
can argue all day long that the spec says this or that, but if every
client expects something else (or something more specific), that's
what we need to deal with. We're not on a mission to create
something that is a stricter implementation of the EC2 API. We're
trying to provide something that people can use.

If someone was trying to offer me something, claiming it's compatible
with something I've used for years, but as we're closing the deal he
says "oh, by the way.. you're probably going to have to change your
tools for this to *actually* work", I'd tell him to take his
"compatibility" and stick it somewhere (in)appropriate.

> It's bad enough that we are spending resources trying to support an API which isn't open and which we don't control, now on top of that we want to support buggy clients that don't follow the spec?

The spec is completely irrelevant. You can call it a compatibility
layer all day long, but if it's *actually* incompatible with what the
clients expect, it's worthless.

> If we know that there are clients out there that make the assumptions then contact the folks that maintain the client and ask them to adjust their code.

How do you suggest we find them?


> If they give you grief, point to the contract and that should settle the issue.

Nonsense. They might be perfectly happy with EC2. If you want them to
switch to OpenStack, that's going to be a tough sell if they can't
reuse their code. To them, it's *you* who's doing something wrong,
because you're doing something different from what EC2 does.

> Though I have some reservations about it, I'm okay offering some support for the EC2 contract. What I'm not okay with is in being in the business of reverse engineering Amazon's EC2 implementation.  Those are two very different things and I think the latter is orders of magnitude more difficult.

Making useful software is difficult. Anyone claiming otherwise is full of it.

Of course we should follow the spec, but if there are well-known
places where reality is different, we need to follow reality. That's
what the clients do.

-- 
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/