Open Stack

On 08/20/2014 11: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:
>>>> ...snip
>>> 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.
>
> This is really where "supported" becomes the mutex binding us all. The
> more "supported" options, the larger the matrix, the more complex a
> user's decision process becomes.

I don't believe this is necessarily true.

A large chunk of users of OpenStack will deploy their cloud using one of 
the OpenStack distributions -- RDO, Ubuntu OpenStack, MOS, or one of the 
OpenStack appliances. For these users, they will select the options that 
their distribution offers (or makes for them).

Another chunk of users of OpenStack will deploy their cloud using things 
like the Chef cookbooks or Puppet modules on stackforge. For these 
users, they will select the options that the writers of those Puppet 
modules or Chef cookbooks have wired into the module or cookbook.

Another chunk of users of OpenStack will deploy their cloud by following 
the upstream installation documentation. This documentation currently 
focuses on the integrated projects, and so these users would only be 
deploying the projects that contributed excellent documentation and 
worked with distributors and packagers to make the installation and use 
of their project as easy as possible.

So, I think there is an argument to be made that packagers and deployers 
would have more decisions to make, but not necessarily end-users of 
OpenStack.

>>   > 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.
>
> 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 believe by picking winners in unsettled spaces, we add more to the 
confusion of users than having >1 option for doing something.

> What we shouldn't do is harm that 1%'s ability to be successful. We should
> foster it and help it grow, but we don't just pull it into the program and
> say "You're ALSO in OpenStack now!"

I haven't been proposing that these competing projects would be "in 
OpenStack now." I have been proposing that these projects live in the 
openstack/ code namespace, as these projects are 100% targeting 
OpenStack installations and users, and they are offering options to 
OpenStack deployers.

I hate the fact that the TC is deciding what "is" OpenStack.

IMO, we should be instead answering questions like "does project X solve 
problem Y for OpenStack users?" and "can the design of project A be 
adapted to pull in good things from project B?" and "where can we advise 
project M to put resources that would most benefit OpenStack users?".

 > and we also don't want to force those
> users to make a hard choice because the better solution is not blessed.

But users are *already* forced to make these choices. They make these 
choices by picking an OpenStack distribution, or by necessity of a 
certain scale, or by their experience and knowledge base of a particular 
technology. Blessing one solution when there are multiple valid 
solutions does not suddenly remove the choice for users.

>> 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.
>
> I'm really not a fan of making it a competitive market. If a space has a
> diverse set of problems, we can expect it will have a diverse set of
> solutions that overlap. But that doesn't mean they both need to drive
> toward making that overlap all-encompassing. Sometimes that happens and
> it is good, and sometimes that happens and it causes horrible bloat.

Yes, I recognize the danger that choice brings. I just am more 
optimistic than you about our ability to handle choice. :)

>> 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).
>
> Right, I think our current situation crowds out diversity, when what we
> want to do is enable it, without confusing the users.

Understood. I know your heart is in the right place, and I know these 
questions have answers that are not black and white.

Appreciate your feedback and thoughts,
-jay