Open Stack

On Fri, May 5, 2017 at 1:02 PM, Michał Jastrzębski <inc007 at gmail.com> wrote:
> 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.
>

No, you've written a complex tool (that you understand) to do it.
That's not the same someone who is not familiar with OpenStack trying
to deploy OpenStack. I too could quickly deploy a decently scaled
infrastructure with some of the tools (fuel/tripleo/puppet/etc), but
the reality is that each one of these tools is inherently hiding the
complexities of OpenStack.  Each (including yours) has their own
flavor of assumptions baked in to make it work.  That is also
confusing for the end user who tries to switch between them and only
gets some of the flexibility of each but then runs face first into
each tool's short comings.  Rather than assuming a tool has solved it
(which it hasn't or we'd all be using the same one by now), how about
we take some time to understand why we've had to write these tools in
the first place and see if there's something we improve on?  Learning
the tool to deploy OpenStack is not the same as deploying OpenStack,
managing it, and turning it around for the true cloud end user to
consume.

> 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
>
> __________________________________________________________________________
> 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