Open Stack

On 07/11/2013 08:35 PM, Randy Bias wrote:
> 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.

Totally. I would never be one to suggest that we need to have the
systems have every characteristic be identical. But, if Ceph and EMC
V-MAX are both being managed by cinder, then I expect things like

cinder give me a 10T volume

To work as expected. I also expect the volume I get to behave like a
block device, and I expect to not need to know things about the backing
store other than that it is giving me a block device.

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

It's the same and not the same that I think is exactly what I've been
getting after. At the end of the day, you want to be able to write an
app for Linux - not needing to write for Montavista and Cray and whatever.

Now here's the fun part... this is about branding and expectations. If
Cray Linux has a special feature that's specifically interesting to an
environment, then that person's app _is_ probably going to be written
for Cray Linux.

What I'm saying here is that it is on us, with our OpenStack hats on, to
care about things that target OpenStack. It is not only not my job to
care about the ways in which Cray OpenStack is different, it's the
opposite of my job. That's the job of Cray, or of any vendor who _is_
actually involved in OpenStack :) and they don't need my help.

OpenStack does need my help, because making an interoperable platform
goes against the basic instincts of every competitive business person
involved here - even though _doing_ it is in their best interests
because of the effect it will have on the market.

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

I'm not against flavors per se (in fact, I believe they've been
considered in-game everytime we've discussed this) but I think it's
important to understand what the win for the end user is there. The
specific win. The thing we want to enable in the ecosystem and for them
to accomplish. I AM against flavors if they are a cop-out for a lazy
product group at one of our member companies who can't get their head
out of a hole in the ground long enough to understand that
differentiation by api divergence is stupid.

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

I have no interest in dictating how OpenStack is configured or deployed.
I'm with you on that.

Linux is not appreciably different in the various flavors, and where it
is, it's a bug. The DISTROS are different in lots of areas - and sadly
growing. Where they are different, it's a giant nightmare. We only
_really_ support Ubuntu and RedHat in OpenStack, and even that is a
nightmare because the two main groups behind that are entrenched in a
set of arbitrary differences that do not, in fact, give any value to the
end user. In fact, I'd say that the upstart/systemd mess is an excelent
specific and recent example of how a lack of being able to work together
has created an ecosystem nightmare.

But Linux only covers the kernel, so there is nobody sitting anywhere
who can bring a clue-bat on the situation.

I don't think we need to be draconian, I don't think we need to dictate
tons of things. In fact, I'd like to keep the number of things where we
dictate to a minimum - but where we do dictate, I want us to dictate
clearly, and I want it to be based on the needs of users who are trying
to consume an interoperable cloud ecosystem.

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