> -----Original Message----- > From: Robert Collins [mailto:robe...@robertcollins.net] > Sent: 29 December 2013 05:36 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [nova] minimum review period for functional > changes that break backwards compatibility > > On 29 December 2013 05:15, John Griffith <john.griff...@solidfire.com> > wrote: > > I think Sean made some good recommendations in the review (waiting 24 > > hours as well as suggesting ML etc). It seems that cases like this > > don't necessarily need mandated time requirements for review but just > > need good core reviewers to say "hey, this is a big deal... we should > > probably get some feedback here" etc. > > > > One thing I am curious about however, Gary made a good point about > > using the "default_ephemeral_format=" config setting to make this > > pretty easy and straight forward. I didn't see any other responses to > > that, and it looks like the patch still uses a default of "none". > > Quick look at the code it seems like this would be a clean way to go > > about things, any reason why this wasn't discussed further? > > We make a point of running defaults in TripleO: if the defaults aren't > generally production suitable, they aren't suitable defaults. If/when we find > a place where there is no sane default, we'll push for having no default and > forcing a choice to be made. > > ext3 wasn't a sane default :). >
ext3 may no longer be the best choice of a default, but that the fact that is already established as the default means that we have to plan any changes carefully. > In fact, for CD environments, the ability to set ext3 via config options means > this change is easy to convert into an arbitrary-time warning period to users, > if a cloud needs to. IMO that puts the emphasis in the wrong place - yes given sufficient notice a CD user can make changes to their existing images to protect them from this change, but that requires them to have sufficient notification to make and test that change. The responsibility should be on reviewers to not allow though changes that break backwards compatibility without some form of notice / deprecation period - not on the operators to have to monitor for and react to changes as they come through. Phil > > -Rob > > -- > Robert Collins <rbtcoll...@hp.com> > Distinguished Technologist > HP Converged Cloud > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
