Open Stack

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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160216/14045c7b/attachment.html>