Open Stack

Randy,

I agree that true interop will involve flavors because there are implementation details that matter.

We'd tried to address this in the certification discussion by requiring BOTH passing certification and publication of a reference architecture.  That way the statement of compatibility would have both API & implementation information.

Perhaps, we should consider allowing the reference architecture to be one of several flavors instead of a unique document per certification.  That would make it easier for everyone to consume (and replicate).

Rob

From: Randy Bias [mailto:randyb at cloudscaling.com]
Sent: Thursday, July 11, 2013 7:36 PM
To: Mark Collier
Cc: foundation-board at lists.openstack.org; openstack-tc at lists.openstack.org; Thierry Carrez
Subject: Re: [Foundation Board] [openstack-tc] Spider "What is Core" Discussion Continued - Monday 7/15 1-3pm Central

This is the area I always get confused on:

On Jul 11, 2013, at 3:14 PM, Mark Collier <mark at openstack.org<mailto:mark at openstack.org>> wrote:
Perhaps the point of clarity is that "snowflakes" happen when two clouds have the same feature but implemented differently to the point of impacting interop (bad news), as opposed to the notion that some clouds simply lack a certain feature altogether, which should be discoverable by an end-user client. The latter is what I had in mind.

I don't understand how people think this can be successfully resolved.  Cloud A implements Ceph, Cloud B implements EMC V-MAX.  These block storage systems are NOT going to operate the same.

The one and only way to make certain OpenStack clouds aren't snowflakes is a rather draconian reference architecture, with little room for interpretation, and a set of validation tests to certify it's to spec.  I can't see any way to make that happen without stomping all over innovation.  Not to mention, I find it hard to believe that the OpenStack community as a whole will be thrilled about having their cloud specifications dictated.  Many people see OpenStack as something moldable that they can use to build clouds for specific purposes.

In fact, I would argue that the very reason that UNIX/Linux "won" the server wars is because it is inherently moldable:

            - MontaVista Linux for embedded Linux applications
            - RHEL / SUSE
            - Ubuntu
            - Cray Linux

These are the same, yet they are not the same.

I believe it would be better to have a variety of reference architectures or "flavors".  That would give room for folks to champion a particular flavor.  Then we might not have snowflakes, but we could allow people to make new flavors on a fairly regular basis, which will result in variety.

There is a reason that Linux wound up with a variety of "winners" in different flavors, but with only a handful seeing super broad adoption based on applicability to use case.  I see no path forward where dictating how OpenStack is configured and deployed is workable.  That's just going to facilitate forking.



Best,



--Randy

Co-founder & CTO, Cloudscaling
Board of Directors, OpenStack Foundation
+1 (415) 787-2253 [SMS or voice]
TWITTER: twitter.com/randybias<http://twitter.com/randybias>
LINKEDIN: linkedin.com/in/randybias<http://linkedin.com/in/randybias>
CALENDAR: doodle.com/randybias<http://doodle.com/randybias>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20130715/7a91fe42/attachment-0001.html>