Open Stack

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.

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

 > If every component has several competing implementations and
> none of them are "official" how many more interaction issues are going
> to trip us up?

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.

If there are multiple actively-developed projects that address the same 
problem space, I think it serves our OpenStack users best to let the 
projects work things out themselves and let the cream rise to the top. 
If the cream ends up being one of those projects, so be it. If the cream 
ends up being a mix of both projects, so be it. The production community 
will end up determining what that cream should be based on what it 
deploys into its clouds and what input it supplies to the teams working 
on competing implementations.

And who knows... what works or is recommended by one deployer may not be 
what is best for another type of deployer and I believe we (the 
TC/governance) do a disservice to our user community by picking a winner 
in a space too early (or continuing to pick a winner in a clearly 
unsettled space).

Just my thoughts on the topic, as they've evolved over the years from 
being a pure developer, to doing QA, then deploy/ops work, and back to 
doing development on OpenStack...

Best,
-jay