Open Stack

Hi Matt,


	Yes, the POSIX argument goes in the SQL92 bucket.  I should start using that example alongside as I think it might be easier for some to understand.  Even in the case of POSIX though, portability isn’t guaranteed, certainly without at least a recompile.  Not all shared libraries of the right revision are in each place or even available to be installed via packaging.  It’s an imperfect world and interoperability is hard.

	I’m not advocating any particular approach.  I’m trying to highlight the inherent contention between choice and interoperability.  I want to solve these problems like everyone else and there are a variety of ways to go about it.  Dictating cloud architectures seems anathema to what OpenStack is trying to accomplish, which means that we need to find another way [1].  Thierry had some good ideas I want to expand on in a separate thread.

	And yes, I think DefCore is headed in the right direction.


--Randy

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

[1] I think everyone has already heard a million times how I think AWS EC2 and GCE are pretty much the same architecture (“elastic cloud”) and I’ve bet Cloudscaling’s future on a version of OpenStack that recreates that architecture, but worth stating it again as a footnote.  There *are* reference architectures out there that OpenStack can and probably should just mimic.  These are the flavors I have been talking about.  The CERN/ANL architectures are similar too and beg for an HPC reference architecture.







On Feb 6, 2014, at 7:07 PM, matt <matt at nycresistor.com> wrote:

> Randy,
> 
>     While I can find no fault in your argument, I would point out that Linux is POSIX compliant.  And I can expect any software I write to a POSIX standardized environment in C to work if I slap it statically compiled into /opt .  I guess that's along the same lines as your SQL 92 argument?   
> 
>    I think there is a need to standardize some open interface architectures that are expected to work the same everywhere.  And I think that is the thrust of this conversation.  Not the specific implementation of service management or where you throw your own Cloud OS binaries.  Just a uniform way for anyone deploying images into OpenStack or integrating their software with it that they can target.  Even if it is as limiting as statically compile all your code and throw it in /opt.
> 
>     I agree with your points, but I wanted to get some clarity on how far you are willing to go on standardizing architecture to support open standardized interfaces for integrators and users?  We probably agree and I think for the most part the arguments being raised here are heading in the same general direction so that's a good sign.
> 
> -Matt
> 
> 
> On Thu, Feb 6, 2014 at 9:52 PM, Randy Bias <randyb at cloudscaling.com> wrote:
> Folks,
> 
> 
> 	I still struggle with this entire conversation.  Linux is not interoperable, how do you expect OpenStack to be so?  RHEL is interoperable with RHEL/Fedora/CentOS.  SUSE with SUSE and so on.  Debian and Ubuntu perhaps more so than most Linux distros.  Take an app you wrote on Cray Linux and run it on Android.  Or recompile it for Android even.  It may run, but it’s certainly not guaranteed.
> 
> 	The simplest example I can think of: HP vs. Rackspace Public Clouds.  HP has chosen a “flat" network scheme.  Rackspace has chosen the “multi_host” option.  On HP, each VM has one NIC.  On Rackspace, they have two NICs.  If you build your app around one assumption vs. the other, then portability becomes difficult, regardless of the APIs in use.  That forces you as the app owner to figure out the differences between these two clouds, regardless of them both being OpenStack and having the OpenStack APIs.
> 
> 	This is only the simplest example.  There are dozens of these kinds of situations where architectural design decisions directly impact application portability and the API is irrelevant.
> 
> 	I see it as a simple issue: we either stifle choice OR we facilitate choice and compromise on interoperability.
> 
> 	I don’t think compromising on interoperability means there is no interop, but more of a baseline of interoperability that is a lowest common denominator (an SQL92 equivalent if you will) and then additional interoperability between “flavors” of OpenStack.
> 
> 	It took years for IPSEC, which was a standard protocol, to actually have decent interoperability and I would argue it’s still difficult.  This is largely because of the amount of choice that was available, which caused complexity.  Choice is the enemy of interoperability.  Choice seems like it has been a key defining attribute of OpenStack.  How can we continue to enable choice, while searching for interop.  The only solution I see is the one I’m proposing (above).  You can try to dictate to the community what they should build, but I can’t see a way that is successful in the long term.  Instead you are likely to cause forks.
> 
> 	Linux is significantly more mature than OpenStack and the Linux Standard Base (LSB) still struggles to unify the various Linux distros in a way that guarantees application portability.  We should be focusing more on driving DefCore to conclusion, building a lowest common denominator baseline, and then figuring out what the “flavors” of interop are above that.
> 
> 	Just my $0.02.
> 
> 
> 
> --Randy
> 
> Founder & CEO, Cloudscaling
> Board of Directors, OpenStack Foundation
> +1 (415) 787-2253 [SMS or voice] 
> TWITTER: twitter.com/randybias
> LINKEDIN: linkedin.com/in/randybias
> CALENDAR: doodle.com/randybias
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Feb 5, 2014, at 4:04 AM, Thierry Carrez <thierry at openstack.org> wrote:
> 
>> With total interoperability, you may have less providers at start, but
>> at least they provide a great experience moving workloads around. And as
>> more join them, it only gets better. Total interoperability is basically
>> the only way to potentially reach one day the nirvana of "lots of
>> providers + great end user experience".
> 
> 
> _______________________________________________
> Foundation mailing list
> Foundation at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/foundation/attachments/20140210/44d8417f/attachment-0001.html>