[openstack-dev] [kolla][kolla-kubernete][tc][openstack-helm]propose retire kolla-kubernetes project

Richard Wellum richwellum at gmail.com
Fri Mar 30 01:32:44 UTC 2018


Hi Gema,

On Thu, Mar 29, 2018 at 2:48 PM Gema Gomez <gema at ggomez.me> wrote:

>
>
> On 29/03/18 18:26, Richard Wellum wrote:
> > 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.
>
> Are you volunteering to drive this effort forward? I'd be happy to help
> define MVP for Rocky.
>

Yes I am.


>
> > 2. Agreement within Kolla core team to learn kolla-kubernetes and start
> > to put a percentage of time into this sub-project.
>
> Whilst this would be ideal, we cannot really force people that have no
> interest in this sub-project to contribute.
>

That's not what I was inferring, more trying to get a shift in attitude
within the Kolla team. For example, if I am working on kolla-kubernetes,
and make a change that breaks kolla-ansible - the Kolla community would
expect me to fix it of course? Same if I added a feature, and didn't apply
and test it with kolla-ansible then the same no? So I'm just saying that
the same should apply in the other direction; which it is currently not. As
a community we should support both deployment methods. Or if we don't then
we are all agreeing that Kolla will not have support on Kubernetes from the
core Kolla community.


>
> > 3. Identify the people who are genuinely interested in working with it
> > within the Kolla team.
>
> +1 if we find enough contributors to make the reasonable list of items
> happen during Rocky.
>
> > 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.
>
> How many contributors are necessary to make MVP?
>
We were doing fairly well with 4-5 contributors imo.

Thanks,

||Rich


>
> Cheers,
> Gema
>
> >
> > Thanks,
> >
> > ||Rich
> >
> >
> > On Wed, Mar 28, 2018 at 1:54 PM Chuck Short <zulcss at gmail.com
> > <mailto: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 <mailto: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 <http://xcodest.me/>
> >
> >
>  __________________________________________________________________________
> >         OpenStack Development Mailing List (not for usage questions)
> >         Unsubscribe:
> >         OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >         <
> http://OpenStack-dev-request@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://OpenStack-dev-request@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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180330/6734eb7e/attachment-0001.html>


More information about the OpenStack-dev mailing list