openstack team mailing list archive

[Jorge Williams <jorge.williams@xxxxxxxxxxxxx>]

If the spec doesn't match the specification then they are admitting that they have a bug.  They broke the contract, we can lobby them to change it or write an implementation that does the right thing.  Or we should not be using the spec at all.  I'd much rather encourage clients to implement against an Open API.

-jOrGe W.


On Jul 8, 2011, at 2:41 PM, Soren Hansen wrote:

> 2011/7/8 Jorge Williams <jorge.williams@xxxxxxxxxxxxx>:
>> 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/

This email may include confidential information. If you received it in error, please delete it.