On Wed, Feb 17, 2016 at 3:15 AM, Steven Dake (stdake) <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. > > 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. > As one of the core reviewers that couldn't make it to the mid-cycle I want to say that I fully agree with this plan. > 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. > In all fairness, we're still pretty early in the life of Kolla, I expect the rate of backports to slow down naturally over time. Martin 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 > >
__________________________________________________________________________ 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