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