Octave, Folks,

"If we had an LTS branch and a solid governance model" - The way to
make it happen is for everyone to show up in the Stable team, do the
work that is need to define/setup etc..

Who is up for it? Please show up in the next weekly meeting and get
active in the work needed to take care of the current stable work and
the work needed to setup a LTS.

Thanks,
Dims


On Fri, May 5, 2017 at 4:23 PM, Octave J. Orgeron
<octave.orge...@oracle.com> wrote:
> 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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims

__________________________________________________________________________
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

Reply via email to