Open Stack

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

Folks,

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.

Regards
-steve


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160220/5406aae8/attachment.html>