Open Stack

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