[openstack-dev] [kolla] Decision of how to manage stable/liberty from Kolla Midcycle
martin.andre at gmail.com
Wed Feb 17 13:08:17 UTC 2016
On Wed, Feb 17, 2016 at 3:15 AM, Steven Dake (stdake) <stdake at cisco.com>
> Hey folks,
> We held a midcycle Feb 9th and 10th. The full notes of the midcycle are
> 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
> 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
> 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.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev