On Fri, May 5, 2017 at 10:48 AM, Chris Dent <cdent...@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 shame. Thanks, -Alex [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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev