Open Stack

On 5 May 2017 at 11:33, Alex Schultz <aschultz at redhat.com> wrote:
> 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
> shame.

Sooo... I always get a little triggered when I hear that OpenStack is
hard to deploy. We've spent last few years fixing it and I think it's
pretty well fixed now. Even as we speak I'm deploying 500+ vms on
OpenStack cluster I deployed last week within one day.

These problems aren't factor of OpenStack growing too fast, it's
tooling that people are using. Granted, it took some time for us to
build these tools, but we did build them. One of reasons why we could
build them is that OpenStack, after being turned into Big Tent allowed
us (Kolla) to quickly join "main herd" of OpenStack and innovate in
our own way. If we'd put lot's of barriers like incubation, we'd still
have same issue with deployment. Stability not always comes from age
of project, sometimes change of methodology alltogether gives you
better stability at the end. Big Tent is meant to allow this kind of
innovation among other things. Setup I'm using now was deployed in
similar manner as this short guide I wrote for Boston summit [1].

Deployment, upgrades and such are problems we're fixing as we go.
Sometimes we make things harder (nova placement API caused a bit of a
headache for deployment tools...), then we make it easier again with
new feature. We might want to put some constrains in terms of
significant, deployment-changing, features merge timelines, but that's
logistics that we handle as community.

I keep hearing that OpenStack lacks leadership, and that's true, but
consider that "leadership" is always limiting for innovation.

[1] https://github.com/inc0/kolla-ansible-workshop

Cheers,
Michal

> 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev