Richard Wellum wrote: > So as a current Kolla-Kubernetes Core - I have a slightly different > opinion than most, I'll try to verbalize it coherently.
Thanks Rich for posting this -- I was really feeling like we missed part of the story. > 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. There is a 3rd option, which I've been advocating for a while. The tension here lies in the fact that the Kolla team is both a low-level provider (Kolla the docker image provider) and a higher-level deployment provider (kolla-ansible, kolla-k8s). The low-level images are used outside of the team (TripleO, openstack-helm), in the team (kolla-ansible) and in the team but by a different group (kolla-k8s). The proposals on the table only partly resolve that tension. Keeping kolla-k8s in kolla, spinning it out or merging it with OSH still make kolla both a low-level and a high-level provider. As long as kolla-ansible shares naming and is produced by the exact same team producing Kolla itself, anything else than kolla-ansible will stay a second-class consumer, breeding validation fears like the one described above. For the structure to match the technical goals, I wonder if "Kolla" should not focus on low-level image production, with the various higher-level Kolla consumers being set up as separate projects on an equal footing. I understand that Kolla and Kolla-Ansible are currently mostly the same group of people, but nothing in OpenStack prevents anyone from being part of two teams. Setting up discrete groups would actually encourage people interested in Kolla but not so much in Kolla-Ansible to join the Kolla team. It would encourage the Kolla team to treat all consumers equally and test their images on those various consumers equally. So my 3rd option would be to split the current Kolla team into three teams with different names, matching the three deliverables that this team currently has. Then if kolla-k8s needs to be sunset or merged with OSH, so be it. -- Thierry Carrez (ttx) __________________________________________________________________________ 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