Open Stack

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


> 
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/foundation/attachments/20140205/ffc2101a/attachment.html>