On March 31, 2018 at 12:35:31 PM, Jeremy Stanley (fu...@yuggoth.org<mailto:fu...@yuggoth.org>) wrote: On 2018-03-31 18:06:07 +0000 (+0000), Steven Dake (stdake) wrote: > I appreciate your personal interest in attempting to clarify the > Kolla mission statement. > > The change in the Kolla mission statement you propose is > unnecessary. [...] I should probably have been more clear. The Kolla mission statement right now says that the Kolla team produces two things: containers and deployment tools. This may make it challenging for the team to avoid tightly coupling their deployment tooling and images, creating a stratification of first-class (those created by the Kolla team) and second-class (those created by anyone else) support for deployment tools using those images. 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. Is the intent to provide "a container-oriented deployment solution and the container images it uses" (kolla-ansible as first-class supported deployment engine for these images) or "container images for use by arbitrary deployment solutions, along with an example deployment solution for use with them" (kolla-ansible on equal footing with competing systems that make use of the same images)? My viewpoint is as all deployments projects are already on an equal footing when using Kolla containers. I would invite the TripleO team who did integration with the Kolla API to provide their thoughts. I haven't kept up with OSH development, but perhaps that team could provide their viewpoint as well. Cheers -steve -- 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
__________________________________________________________________________ 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
