Open Stack

On Friday, August 10, 2012 at 22:53 PM, George Reese wrote:

> First, thanks to Andrew for starting this thread. I think it's an important discussion.
>  
> Second, the problem with the analogies made so far is, IMHO, at the API level and what it does to the ecosystem.
>  
> Let's take, for example, Apache HTTP Client stuff. 3.1 and 4.x are wildly different object models. But that's OK for the Apache model in a way that isn't for OpenStack.
Aren't you making the wrong comparison here?  This might apply to the OS API client libraries, or euca2ools (which is NOT an OpenStack project), but this comparison does not apply to the OpenStack services or EC2 endpoint compatibility.  Instead, the comparison of EC2 endpoint compatibility should be made to Apache's HTTP endpoint, their httpd.

A better question is: Has the Apache httpd broken HTTP compatibility in any significant way? Besides, perhaps, from allowing you to configure it in a broken manner?

In fact, this might be a good comparison, because Apache's httpd doesn't HAVE to be deployed in a standards-compliant way, although tools (i.e. browsers) and operators have figured out how to make this work, and to a large degree, people are able to successfully load webpages served by the Apache httpd.

In a similar way, OpenStack Nova installations may vary greatly in their behavior. They don't HAVE to be deployed in a standards-complaint way (whatever that means); Yet, hopefully, people will be able to successfully launch instances served by OpenStack Nova with a common set of tools.

I'm often advocating compatible clouds over advanced client API wrappers (such as Dasein), but the reality is that it needs to happen on both ends. The cloud server software needs to enable a compatible and standards-compliant service endpoint, enforced or not… and the client API libraries need to be flexible enough to handle a variety of services that might not be 100% identical.  Just like the HTTP servers and client libraries that we have today.

Regards,
Eric Windisch