Open Stack

On 08/20/2014 09:54 PM, Clint Byrum wrote:
> Excerpts from Jay Pipes's message of 2014-08-20 14:53:22 -0700:
>> On 08/20/2014 05:06 PM, Chris Friesen wrote:
>>> On 08/20/2014 07:21 AM, Jay Pipes wrote:
>>>> Hi Thierry, thanks for the reply. Comments inline. :)
>>>>
>>>> On 08/20/2014 06:32 AM, Thierry Carrez wrote:
>>>>> If we want to follow your model, we probably would have to dissolve
>>>>> programs as they stand right now, and have blessed categories on one
>>>>> side, and teams on the other (with projects from some teams being
>>>>> blessed as the current solution).
>>>>
>>>> Why do we have to have "blessed" categories at all? I'd like to think of
>>>> a day when the TC isn't picking winners or losers at all. Level the
>>>> playing field and let the quality of the projects themselves determine
>>>> the winner in the space. Stop the incubation and graduation madness and
>>>> change the role of the TC to instead play an advisory role to upcoming
>>>> (and existing!) projects on the best ways to integrate with other
>>>> OpenStack projects, if integration is something that is natural for the
>>>> project to work towards.
>>>
>>> It seems to me that at some point you need to have a recommended way of
>>> doing things, otherwise it's going to be *really hard* for someone to
>>> bring up an OpenStack installation.
>>
>> Why can't there be multiple recommended ways of setting up an OpenStack
>> installation? Matter of fact, in reality, there already are multiple
>> recommended ways of setting up an OpenStack installation, aren't there?
>>
>> There's multiple distributions of OpenStack, multiple ways of doing
>> bare-metal deployment, multiple ways of deploying different message
>> queues and DBs, multiple ways of establishing networking, multiple open
>> and proprietary monitoring systems to choose from, etc. And I don't
>> really see anything wrong with that.
>>
>
> This is an argument for loosely coupling things, rather than tightly
> integrating things. You will almost always win my vote with that sort of
> movement, and you have here. +1.

I mostly agree, but I think we should distinguish between things that 
are "possible", and things that are "supported".  Arguably, anything 
that is "supported" should be tested as part of the core infrastructure 
and documented in the core OpenStack documentation.

>>> We already run into issues with something as basic as competing SQL
>>> databases.
>>
>> If the TC suddenly said "Only MySQL will be supported", that would not
>> mean that the greater OpenStack community would be served better. It
>> would just unnecessarily take options away from deployers.

On the other hand, if the community says explicitly "we only test with 
sqlite and MySQL" then that sends a signal that anyone wanting to use 
something else should plan on doing additional integration testing.

I've stumbled over some of these issues, and it's no fun. (There's still 
an open bug around the fact that sqlite behaves differently than MySQL 
with respect to regex.)

>> IMO, OpenStack should be about choice. Choice of hypervisor, choice of
>> DB and MQ infrastructure, choice of operating systems, choice of storage
>> vendors, choice of networking vendors.
>>
>
> Err, uh. I think OpenStack should be about users. If having 400 choices
> means users are just confused, then OpenStack becomes nothing and
> everything all at once. Choices should be part of the whole not when 1%
> of the market wants a choice, but when 20%+ of the market _requires_
> a choice.

I agree.

If there are too many choices without enough documentation as to why 
someone would choose one over the other, or insufficient testing such 
that some choices are theoretically valid but broken in practice, then 
it's less useful for the end users.

Chris