My $0.02 is that this puts us in a very vulnerable position. Amazon can introduce bugs/nuances at will which can have serious implications for us -- if they want to disrupt our efforts it's very easy for them to do so. Reverse engineering Amazon's EC2 can also take a serious amount of effort -- we need to be continuously testing against it etc. Are we doing this now?
When Rackspace makes the switch you will automagically have a lot of clients with very good incentive to use our API and to give local deployments of OpenStack a try. I'm not convinced that we *need* EC2 in the long run precisely because of this. -jOrGe W. On Jul 8, 2011, at 10:23 AM, Sandy Walsh wrote: > I don't think this is a technical issue, it's a business issue. If we want > adoption, we have to reduce switching friction. Sadly, this means EC2 > bugs/nuances and all. > > The better a job we do of this, the easier it will be for users to transition > from EC2 to OpenStack and benefit from all the chocolatey goodness we're > baking into it. > > $0.02 > > > ________________________________________ > From: openstack-bounces+sandy.walsh=rackspace....@lists.launchpad.net > [openstack-bounces+sandy.walsh=rackspace....@lists.launchpad.net] on behalf > of Jorge Williams [jorge.willi...@rackspace.com] > Sent: Friday, July 08, 2011 12:01 PM > To: Soren Hansen > Cc: Ewan Mellor; openstack@lists.launchpad.net > Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it > worth the effort? > > 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.mel...@eu.citrix.com>: >>>> 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@lists.launchpad.net >> 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. > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > 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. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
