Open Stack

This thread has been very interesting to read and I find merit in ALL of the viewpoints.  Most of them are already part of the discussion record and have been factored into the DefCore plans (including the multiple uses of "core" and "brand").

The whole point of "spider" was that there are multiple correct yet divergent viewpoints around OpenStack.  Alan and I called these "tensions" and felt they were healthy in keeping us balanced.

I am also very impatient to move faster; however, experience has shown that we build consensus when we resolve concrete issues and chip away problems like "core", "interop" and "brand."

In this cycle, we're making progress on defining core capabilities that should help move towards both interop and brand usage.  Some of the issues in this thread are addressed specifically in how we are defining the criteria used to select-must pass tests (criteria list<http://robhirschfeld.com/2014/01/07/defcore-critieria/>).  We could use help on this and support helping explain the approach.

Note: There is also conflict on commercial vs. project brand use that we're running into and will need further clarification.   I'd been hoping this could hold off until after the must-pass test cycle.

Rob

Date: Fri, 07 Feb 2014 10:27:19 +0100
From: Thierry Carrez <thierry at openstack.org>
To: Randy Bias <randyb at cloudscaling.com>
Cc: "foundation at lists.openstack.org" <foundation at lists.openstack.org>
Subject: Re: [OpenStack Foundation] The two types of interoperability
Message-ID: <52F4A6F7.3010205 at openstack.org>
Content-Type: text/plain; charset=windows-1252

Randy Bias wrote:
> [...]
> I see it as a simple issue: we either stifle choice OR we facilitate
> choice and compromise on interoperability.
> [...]

Yes, that's another way to frame the question. My point in the original email is that I know there are, in OpenStack, strong proponents of both end goals. We shouldn't delay anymore that necessary discussion on what should be our common long-term goal.

That said, I like Nicolas's point about the various types of trademark usage (project names, distributions, deployments) and that slightly different rules could be used for each of those. I also agree with Boris that trademark usage is not the only weapon we could use to encourage portability of workloads. And I like your point that even in the case of "total interoperability", specific deployment choices will affect portability, so unless you build architectural clones (which I think nobody actually wants), interoperability will never be perfect.

To come back to your point, IMHO there is value in maximizing the *feature set* that is common between deployments, even if deployment architectures differ. You might need to adjust your workload to go from a flat to a multi_host deployment, or have your app support both cases.

But if you rely on Heat API on the first one and the other one doesn't propose Heat at all, you just have to rewrite your workload completely.

Cheers,

--
Thierry Carrez (ttx)


------------------------------

_______________________________________________
Foundation mailing list
Foundation at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation


End of Foundation Digest, Vol 27, Issue 7
*****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/foundation/attachments/20140210/96bb6676/attachment.html>