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. > 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. > 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? Cheers, Gema > > Thanks, > > ||Rich > > > On Wed, Mar 28, 2018 at 1:54 PM Chuck Short <zul...@gmail.com > <mailto:zul...@gmail.com>> wrote: > > +1 > > Regards > chuck > On Wed, Mar 28, 2018 at 11:47 AM, Jeffrey Zhang > <zhang.lei....@gmail.com <mailto:zhang.lei....@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-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev