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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
