[openstack-dev] [kolla][vote] port neutron thin containers to stable/liberty
Steven Dake (stdake)
stdake at cisco.com
Sat Feb 20 13:38:39 UTC 2016
From: Steven Dake <stdake at cisco.com<mailto:stdake at cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Saturday, February 20, 2016 at 6:28 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: [openstack-dev] [kolla][vote] port neutron thin containers to stable/liberty
There were not enough core reviewers to pass a majority approval of the neutron thin container backport idea, so we separated it out from fixing stable/liberty itself.
I am going to keep voting open for *2* weeks this time. The reason for the two weeks is I would like a week of discussion before people just blindly vote ;)
Voting begins now and concludes March 4th. Since this is a policy decision, no veto votes are permitted, just a +1 and a -1. Abstaining is the same as voting -1.
Just kicking this conversation off, this feels a lot like an exception to me. The problem with exceptions is that if we make one, we set a precedent that we will make exceptions in the future. This means stable/* could become free for feature backport requests of all types. For example, Id like reconfigure in stable/liberty. I really need it for $$DAYJOB$$ but I don't think its the right way to manage the stable/liberty branch (backporting reconfigure). In the same way, I think thin neutron containers are in the same category - a feature.
We have already made a decision we are going to fix Liberty so its stable because of data loss problems. While we are using new features to do this, the rationale is that we have a highly critical defect with the implementation and design of stable/liberty that needs to be rectified. In my mind, this is a different scenario then a backport of a pure feature for feature's sake.
Even backporting reconfgiure would make more sense under a critical defect (the fact that COPY_ONCE doesn't restart containers on redeploy so once a config is deployed, its permanent). I can't think of such argument for neutron thin containers although it is 6:30AM :).
I'd like to hear that argument.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev