Comments inline
From: Sam Yaple <sam...@yaple.net<mailto:sam...@yaple.net>> Reply-To: "s...@yaple.net<mailto:s...@yaple.net>" <s...@yaple.net<mailto:s...@yaple.net>>, "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Tuesday, February 16, 2016 at 11:42 AM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [kolla] Decision of how to manage stable/liberty from Kolla Midcycle On Tue, Feb 16, 2016 at 6:15 PM, Steven Dake (stdake) <std...@cisco.com<mailto:std...@cisco.com>> wrote: Hey folks, We held a midcycle Feb 9th and 10th. The full notes of the midcycle are here: https://etherpad.openstack.org/p/kolla-mitaka-midcycle We had 3 separate ~40 minute sessions on making stable stable. The reason for so many sessions on this topic were that it took a long time to come to an agreement about the problem and solution. There are two major problems with stable: Stable is hard-pinned to 1.8.2 of docker. Ansible 1.9.4 is the last version of Ansible in the 1 z series coming from Ansible. Ansible 1.9.4 docker module is totally busted with Docker 1.8.3 and later. Stable uses data containers. Data containers used with Ansible can result, in some very limited instances, such as an upgrade of the data container image, data loss. We didn't really recognize this until recently. We can't really fix Ansible to behave correctly with the data containers. This point is not correct. This is not an issue with Ansible, rather with Docker and persistent data. The solution to this problem is named volumes with Docker, which Docker has been moving toward and was release in Docker 1.9. Agreed. The solution: Use the kolla-docker.py module to replace ansible's built in docker module. This is not a fork of that module from Ansible's upstream so it has no GPLv3 licensing concerns. Instead its freshly written code in master. This allows the Kolla upstream to implement support for any version of docker we prefer. We will be making 1.9 and possibly 1.10 depending on the outcome of a thin containers vote the minimum version of docker required to run stable/liberty. We will be replacing the data containers with named volumes. Named volumes offer a similar functionality (persistent data containment) in a different implementation way. They were introduced in Docker 1.9, because data containers have many shortcomings. This will require some rework on the playbooks. Rather then backport the 900+ patches that have entered master since liberty, we are going to surgically correct the problems with named volumes. We suspect this work will take 4-6 weeks to complete and will be less then 15 patches on top of stable/liberty. The numbers here are just estimates, it could be more or less, but on that order of magnitude. The above solution is what we decided we would go with, after nearly 3 hours of debate ;) If I got any of that wrong, please feel free to chime in for folks that were there. Note there was a majority of core reviewers present, and nobody raised objection to this plan of activity, so I'd consider it voted and approved :) There was not a majority approval for another proposal to backport thin containers for neutron which I will handle in a separate email. Going forward, my personal preference is that we make stable branches a low-rate-of-change branch, rather then how it is misnamed to to imply a high rate of backports to fix problems. We will have further design sessions about stable branch maintenance at the Austin ODS. Regards -steve __________________________________________________________________________ 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 To add to this, this would be a y change to Kolla. So this release would be a 1.1.0 release rather than a 1.0.1 release. y releases are not desired, but in this case would be needed to do the changes we purpose. Thanks Sam, I definitely left this key information out unintentionally and it is important; we will tag 1.1.0 when this work is completed and that will not present a data loss scenario. Regards -steve
__________________________________________________________________________ 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
