openstack team mailing list archive

[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.

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?  Where do we draw the line? I'm all for being flexible and forgiving in what we expect from clients, but I don't think we should be making serious engineering decisions based on the fact that a client developer made a bad assumption or didn't read the spec.

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.  If they give you grief, point to the contract and that should settle the issue. It's to their interest to support as many deployments of the API as possible. It's not our responsibility to support their buggy code.

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.  In fact I would argue that reverse engineering EC2 is a project onto itself. That means that when EC2 has a bug, we need to replicate it etc.  That's almost impossible and it makes it really easy for Amazon to disrupt our efforts if they so wish.  What's more, it gets in the way of our ability to innovate and break new ground.

-jOrGe W.

On Jul 8, 2011, at 7:39 AM, Soren Hansen wrote:

> 2011/7/8 Ewan Mellor <Ewan.Mellor@xxxxxxxxxxxxx>:
>>> The whole point of supporting the EC2 API is to support people's
>>> existing tools and whatnot. If we follow the spec, but the clients
>>> don't work, we're doing it wrong.
>> True enough.  However, in the case where we've got a demonstrated divergence from the spec, we should report that against the client.  I agree that we want to support pre-existing tools, but it's less clear that we want to support _buggy_ tools.
> 
> We do. We have to. We have no way to know what sort of clients people
> are using. We can only attempt to check the open source ones, but
> there's likely loads of other ones that people have built themselves
> and never shared. Not only do people have to be able, motivated and
> allowed to change their tools to work with OpenStack, they also need
> to *realise* that this is something that needs to happen. We can't
> assume the symptoms they'll experience even gives as much as a hint
> that the ID's they're getting back is too long. They may just get a
> general error of some sort.
> 
> If we a) expect people to consume the EC2 API we expose, and (more
> importantly) b) expect ISP's to offer this API to their customers, it
> needs to be as close to "just another EC2 region" as possible.
> 
>> If Amazon turn out to be resistant to fixing that problem, then we'll obviously have to accept that and move on, but we should at least give them a chance to respond on that.
> 
> Amazon is not the problem. At least not the only problem. I'm not even
> going to begin to guess how many different tools exist to talk to the
> EC2 API.
> 
> -- 
> Soren Hansen        | http://linux2go.dk/
> Ubuntu Developer    | http://www.ubuntu.com/
> OpenStack Developer | http://www.openstack.org/
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

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