Open Stack

+1.
________________________________________
From: Octave J. Orgeron [octave.orgeron at oracle.com]
Sent: Friday, May 05, 2017 1:23 PM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [tc] [all] OpenStack moving both too fast and too slow at the same time

Thank you Alex for the points you made below. These are some of the big
issues that I see all OpenStack customers and operators struggling with.
Regardless of the tools that the community or vendors put on the table,
OpenStack is still a very complicated piece of technology to deploy and
manage. Even if we look at trippleo, kolla, puppet, Fuel, JuJu, etc.
they address very specific use-cases. Most will handle deploying a basic
HA control plane and configure things that are suited for a dev/test
setup, demo, or POC type of use-case. But do they handle a production
ready deployment for a bank, telco, retailer, or government? Is
everything configured to handle HA, scale, security, auditing,
multi-tenancy, etc. with all of the knobs and options set the way the
customer needs? Do we end up with ceilometer, aodh, gnocchi, ELK, etc.
all configured optimally? How about networking and security? How about
upgrades? Can you expect people to hit an upgrade button and not have
anything break? Let's be realistic here.. these tools are all good
starting points, but you're going to have to get your hands dirty at
some level to configure OpenStack to fit your actual business and
technical requirements. The life-cycle management of OpenStack is not
easy and requires a lot of resources. Sure vendors can try to fill the
void, but everything they build is on quicksand.

This is why you see vendors and major consulting houses jumping all over
this to fill the void with professional services. There are plenty of
big shops that are now looking at ways to out-source the management of
OpenStack because of how complex it is to manage and maintain. BTW, this
is the biggest market sign that a product is too complicated.

 From a vendors perspective, it's incredibly difficult to keep up with
the releases because once you get your automation tooling and any extra
value-added components integrated with a release, it's more than likely
already behind or EOL. Plus there won't be enough soak time with
customers to adopt it! Not only that, but by the time you make something
work for customers, there is a very high chance that the upstream
version of those components will have changed enough that you'll have to
either patch, re-architect, or slash and burn what you've already
delivered to your customers. Not to mention it maybe impossible to
upgrade your customers in a seamless or automated fashion. This is why
customers will stick to an older release because the upgrade path is too
painful.

If you consider the realities of all of the above, what ends up
happening? Enterprise customers will end up sticking to an older release
or paying someone else to deal with the complexity. This places vendors
at risk because there isn't a clear revenue model that can sustain the
engineering overhead required for maintaining and developing their
distribution. If customers aren't buy more or upgrading, then who's
keeping the lights on? You can only charge so much for support. So they
end up being bought or going under. Which leaves customers with fewer
choices and more risk.

So ultimately, the right way to fix this is to have an LTS branch and
for there to be better governance around how new features are
introduced. There needs to be more customer and vendor driven
involvement to solidifying a core set of features that everyone can rely
on working consistently across releases and upgrades. When new features
or enhancements come along, there should be more emphasis on usability,
sustainability, and upgradeability so that customers and vendors are not
stuck.

If we had an LTS branch and a solid governance model, both vendors and
customers would benefit greatly. It would help buffer the chaos of the
bleeding edge away from customers and allow vendors to deliver and
support them properly.

Octave

On 5/5/2017 12:33 PM, Alex Schultz wrote:
> 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


__________________________________________________________________________
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