Open Stack

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/20140206/cc99bc97/attachment-0001.html>