[openstack-dev] [tc] [all] OpenStack moving both too fast and too slow at the same time

Alex Schultz aschultz at redhat.com
Fri May 5 18:33:49 UTC 2017

On Fri, May 5, 2017 at 10:48 AM, Chris Dent <cdent+os at anticdent.org> wrote:
> On Fri, 5 May 2017, Alex Schultz wrote:
>> You have to understand that as I'm mainly dealing with having to
>> actually deploy/configure the software, when I see 'new project X'
>> that does 'cool new things Y, Z' it makes me cringe.  Because it's
>> just added complexity for new features that who knows if they are
>> actually going to be consumed by a majority of end users.  I see a
>> lot of new features for edge cases while the core functionally
>> (insert the most used project configuration) still have awkward
>> deployment, configuration and usability issues. But those aren't
>> exciting so people don't want to work on them...
> Would it be accurate to say, then, that from your perpsective the
> tendency of OpenStack to adopt new projects willy nilly contributes
> to the sense of features winning out over deployment, configuration
> and usability issues?

It does not help.

> I think a lot of project contributors may not really see it that way
> because they think of their project and within that project there is
> a constant effort to clean things up, address bugs and tech debt,
> and try to slowly but surely evolve to some level of maturity. In
> their eyes those new projects are something else separate from their
> project.
> From the outside, however, it is all OpenStack and maybe it looks
> like there's loads of diffuse attention.
> If that's the case, then a question is whether or not the people who
> are spending time on those new projects would be spending time on
> the older projects instead if the new projects didn't exist. I don't
> know, but seems unlikely.

So there's a trade off and I don't think we can just restrict entry
because some projects aren't user friendly.  I see it as a common
issue across all projects. Some are better than others, but what I
would like to see is the bar for usability raised within the OpenStack
community such that the end user (and deployer/operator) are all taken
into consideration.  For me the usability also goes with adoption. The
easier it is to consume, the easier it would be to adopt something.
If  you take a look at what is required to configure OpenStack for a
basic deployment, it is not easy to consume.  If you were to compare
the basic getting started/install guide for Kubernetes[0] vs
OpenStack[1], you can see what I mean about complexity.  I think just
the install guide for neutron on a controller node[2] is about the
same length as the kubernetes guide.  And we think this is ok?  We
should keep adding additional installation/management complexity for
each project?  You could argue that OpenStack has more features or
more flexible so it's apples to oranges but I don't think it has to be
if we worked on better patterns for configuration/deployment/upgrades.
It feels like OpenStack is the thing that you should pay professional
services to deploy rather than I do it yourself.  And I think that's a


[0] https://kubernetes.io/docs/getting-started-guides/centos/centos_manual_config/
[1] https://docs.openstack.org/newton/install-guide-rdo/
[2] https://docs.openstack.org/newton/install-guide-rdo/neutron-controller-install.html

> --
> Chris Dent                  ┬──┬◡ノ(° -°ノ)       https://anticdent.org/
> freenode: cdent                                         tw: @anticdent
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list