Open Stack

Hi,

So as a current Kolla-Kubernetes Core - I have a slightly different opinion
than most, I'll try to verbalize it coherently.

Lets talk about what Kolla is:

Kolla is a project that builds OpenStack docker images, stores them on
dockerhub, and provides tools to build your own images from your own
source. Both the images and the tools it provides, are widely used, very
popular and extremely stable; TripleO, openstack-helm and kolla-ansible to
name a few are all deployment methods that use Kolla.

Kolla has two sub-projects, that both revolve around deployment methods;
kolla-ansible and kolla-kubernetes. Kolla-ansible is proven, stable and
used by many in the industry. Part of Kolla's quality is it's rock-solid
dependability in many scenarios. As Kubernetes took over most of the COE
world, it's only correct that the Kolla team created this sub-project; if
swarm became suddenly very popular then we should create a kolla-swarm
sub-project.

So if we abandon kolla-kubernetes ('sunset' seems much more romantic
admittedly) - we are abandoning the core Kolla team's efforts in this
space. No matter how good openstack-helm is (and I've deployed it, know a
lot of the cores and it's truly excellent and well driven), what happens
down the line if openstack-helm decide to move on from Kolla - say
focussing on Loci images or a new flavor that comes along? Then Kolla the
core project, will no longer have any validation of it's docker
images/containers running on Kubernetes. That to me is the big risk here.

The key issue in my opinion is that the core Kolla team has focussed on
kolla-ansible almost exclusively, and have not migrated to using
kolla-kubernetes as well. As the code base has stagnated, the gates get
intro trouble, and new features and configurations added to kolla-ansible
are not translated to kolla-kubernetes.

So I think the real question is not whether we should 'sunset'
kolla-kubernetes the sub-project, but should we drop Kolla support on
Kubernetes? Relying on a different team to do so is probably not the
answer; although it's the one championed in this thread.

In my opinion we should set some realistic goals before we sunset:

1. Pick a feature set for a Rocky v1.0 release, and commit to trying to get
there. We have a long list of items, maybe pair this down to something
reasonable.
2. Agreement within Kolla core team to learn kolla-kubernetes and start to
put a percentage of time into this sub-project.
3. Identify the people who are genuinely interested in working with it
within the Kolla team.

Without '2' I think sunsetting is the way forward, but the risks should be
fully understood and hopefully I've made a case for what those are above.

Thanks,

||Rich


On Wed, Mar 28, 2018 at 1:54 PM Chuck Short <zulcss at gmail.com> wrote:

> +1
>
> Regards
> chuck
> On Wed, Mar 28, 2018 at 11:47 AM, Jeffrey Zhang <zhang.lei.fly at gmail.com>
> wrote:
>
>> There are two projects to solve the issue that run OpenStack on
>> Kubernetes, OpenStack-helm, and kolla-kubernetes. Them both
>> leverage helm tool for orchestration. There is some different perspective
>> at the beginning, which results in the two teams could not work together.
>>
>> But recently, the difference becomes too small. and there is also no
>> active
>> contributor in the kolla-kubernetes project.
>>
>> So I propose to retire kolla-kubernetes project. If you are still
>> interested in running OpenStack on kubernetes, please refer to
>> openstack-helm project.
>>
>> --
>> Regards,
>> Jeffrey Zhang
>> Blog: http://xcodest.me
>>
>> __________________________________________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180329/27e59967/attachment.html>