Thanks to all guys. The mail is a little off-topic. First of all, let us back to the topic of this mail.
**kolla-kubernetes** The root issue for kolla-kubernetes is no active contributors. if more person is interested in this project, I would like to give more time to this project. But leave it in kolla governance may not good for its growth. Because it is a **totally different** technical stack with kolla-ansible. so migrate it to TC governance should the best solution. **for kolla and kolla-ansible split** kolla(container) is widely used by multi-project (TripleO, OSH). And I also heard some internal projects are using it too. kolla and kolla-ansible are well decoupled. The usage or the API kolla provides always stable and backward compatible. kolla images are also used in many produce environment through different deployment tools So kolla(container) is worth say "provide production-ready containers". This should not be negative, just because of kolla and kolla-ansible are under the same team governance. the team split would let people fouse on one thing and make it looks better. but we have two different teams, kolla-core team, and the kolla-ansible-core team already. anyone is welcome to join one of the team. But in fact, the members of these two teams are almost the same. if we split the team now, all we gain is making chaos and hard to manage. I think it may be proper time when the members of kolla-core team and the kolla-ansible-core team is different (50% maybe?). On Sun, Apr 1, 2018 at 7:16 AM, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2018-03-31 22:07:03 +0000 (+0000), Steven Dake (stdake) wrote: > [...] > > The problems raised in this thread (tension - tight coupling - > > second class citizens - stratification) was predicted early on - > > prior to Kolla 1.0. That prediction led to the creation of a > > technical solution - the Kolla API. This API permits anyone to > > reuse the containers as they see fit if they conform their > > implementation to the API. The API is not specifically tied to > > the Ansible deployment technology. Instead the API is tied to the > > varying requirements that various deployment teams have had in the > > past around generalized requirements for making container > > lifecycle management a reality while running OpenStack services > > and their dependencies inside containers. > [...] > > Thanks! That's where my fuzzy thought process was leading. Existence > of a stable API guarantee rather than treating the API as "whatever > kolla-ansible does" significantly increases the chances of other > projects being able to rely on kolla's images in the long term. > -- > Jeremy Stanley > > __________________________________________________________________________ > 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me
__________________________________________________________________________ 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