So my take on the issue. I think splitting Kolla and Kolla-Ansible to completely new project (including name change and all) might look good from purity perspective (they're effectively separate), but would cause chaos and damage to production deployments people use. While code will be the same, do we scrub "kolla" name from kolla-ansible code? Do we change config paths? Configs lands in /etc/kolla so I guess new project shouldn't do that? Not to mention that operators are used to this nomenclature and build tools around it (for example Kayobe) and there is no telling how many production deployments would get hurt. At the same time I don't think there is much to gain from split like that, so that's not really practical.
We can do this for Kolla-kubernetes as it hasn't released 1.0 so there won't (or shouldn't) be production environments based on it. We already have separate core teams for Kolla and Kolla-Ansible. From my experience organizing PTG and other events for both (or rather all 3 deliverables) together makes sense and makes scheduling of attendance much easier. On 31 March 2018 at 11:06, Steven Dake (stdake) <std...@cisco.com> wrote: > On March 31, 2018 at 6:45:03 AM, Jeremy Stanley (fu...@yuggoth.org) wrote: > > [...] > Given this, it sounds like the current Kolla mission statement of > "provide production-ready containers and deployment tools for > operating OpenStack clouds" could use some adjustment to drop the > production-ready containers aspect for further clarity. Do you > agree? > [...] > > I appreciate your personal interest in attempting to clarify the Kolla > mission statement. > > The change in the Kolla mission statement you propose is unnecessary. > > Regards > > -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 > __________________________________________________________________________ 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
