Open Stack

----- Original Message -----

| From: "Troy Toman" <troy at tomanator.com>
| To: "Nicolas Barcet" <nicolas at barcet.com>
| Cc: foundation at lists.openstack.org
| Sent: Wednesday, February 5, 2014 8:08:02 AM
| Subject: Re: [OpenStack Foundation] The two types of interoperability

| On Feb 5, 2014, at 7:13 AM, Nicolas Barcet < nicolas at barcet.com > wrote:

| | Having been part of the defcore committee for a bit, I must say that
| 
| | the work that is being done there has a very good intent. It is
| 
| | also great to define what type of interoperability we want to mesure
| 
| | and offer is key to providing OpenStack users valuable information
| 
| | they expect.
| 

| | However, as part of this committee, I have failed to make myself
| 
| | heard on a very key point in my mind. The notion of core, or
| 
| | interoperability, means 3 different things, because of the nature of
| 
| | what we do and the population they address:
| 
| | 1/ Which projects are part of core and can call themselves
| 
| | OpenStack?
| 
| | -> Interesting to developpers and distribution builders
| 

| | 2/ Which distributions are based on core OpenStack and can therefore
| 
| | call themselves OpenStack?
| 
| | -> Interesting to cloud operators that want to pick an OpenStack
| 
| | distribution
| 

| | 3/ Which clouds are delivering an OpenStack experience and can call
| 
| | themselves OpenStack?
| 
| | -> Interesting to cloud users and enterprises wanting to pick the
| 
| | right infrastructure to deploy their application on
| 

| | The current bylaws of the foundation fails to make this distinction in
| 
| | defining the term Core, and therefore the DefCore committee has failed
| 
| | to distinguish those 3 aspects and is producing what seems to me a
| 
| | bunch of rules which, by trying to satisfy 3 very different things with
| 
| | a single set, is going to, at best, produce some lowest common
| 
| | denominator set.
| 

| I think Nick begins the discussion around a very important point that I have
| also, so far, failed to articulate well. We keep tying to solve multiple
| problems with one solution.

| (Here is where I started articulate, in my words, those problems and realized
| It was essentially a repeat Nick's)

| "Core" can't solve all of these with one brand/test/process and be very good
| at it. I don't think every feature/capability/option in Nova should be
| required in an "OpenStack cloud", for instance. But, just branding a
| collection of capabilities as OpenStack without anyway to extend the brand
| to the major projects is not proving to be a satisfying approach either. We
| need to find the best approach for these specific problems vs. trying to
| stretch "core" to be everything.

Strongly agree :) 

To me the key interoperability question is "can I as a user easily understand the portability of my workload across different clouds that use the OpenStack label". While one approach to this is that all clouds labeled "OpenStack" have exactly the same "core" API/toolset surface, I doubt this is a very practical approach. For example, I know many people who are deploying OpenStack without Swift, and that makes perfect sense for them. What they would care about is whether the code that wrote against their API (Nova, Glance, etc.) would work against another cloud. So if we instead approach the problem from a sense of "how can we give people a mental framework and perhaps a set of tools for understanding interoperability", I think we will end up at a much better place. 

And I definitely agree that using the term "core" for othis is extra confusing, as the same term applies to a projects status. However, just because a project is "core" does not mean that all instances of it expose the same API/toolset surface, due to API extensions, different release versions, different configuration options, different flavors, etc. 

Dan 

| | So, yes, we need to determine which type of interoperability we want
| 
| | to achieve, but I do think that we need to define what is Core
| 
| | independently for each one of the 3 cases above. The perception of
| 
| | what OpenStack is cannot be defined independently of the type of users
| 
| | and what interactions they are going to have with OpenStack. and this
| 
| | may very well have ties onto which body has the right to validate what
| 
| | Core is.
| 

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

| _______________________________________________
| Foundation mailing list
| Foundation at lists.openstack.org
| https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FGmAC0C4XZyIEAvm3CvAWMRhdLzlce10LeJNK46NsWU%3D%0A&m=BwXFws9S3oB5yn4XyrLBKqyCiMCR2a6GqTO5yTehi3Y%3D%0A&s=fa24bbe732e8d92f221c82a92ee0c6ad7edebdf49febaea76475146bb9c23be9
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/foundation/attachments/20140205/767b4af3/attachment-0001.html>