-----Original Message----- From: John Griffith <john.griffi...@gmail.com> Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org>> Date: September 25, 2014 at 12:27:52 To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Ironic] Get rid of the sample config file
> On Thu, Sep 25, 2014 at 12:34 PM, Devdatta Kulkarni < > devdatta.kulka...@rackspace.com> wrote: > > > Hi, > > > > We have faced this situation in Solum several times. And in fact this was > > one of the topics > > that we discussed in our last irc meeting. > > > > We landed on separating the sample check from pep8 gate into a non-voting > > gate. > > One reason to keep the sample check is so that when say a feature in your > > code fails > > due to some upstream changes and for which you don't have coverage in your > > functional tests then > > a non-voting but failing sample check gate can be used as a starting point > > of the failure investigation. > > > > More details about the discussion can be found here: > > > > http://eavesdrop.openstack.org/meetings/solum_team_meeting/2014/solum_team_meeting.2014-09-23-16.00.log.txt > > > > > > - Devdatta > > > > ------------------------------ > > *From:* David Shrewsbury [shrewsbury.d...@gmail.com] > > *Sent:* Thursday, September 25, 2014 12:42 PM > > *To:* OpenStack Development Mailing List (not for usage questions) > > *Subject:* Re: [openstack-dev] [Ironic] Get rid of the sample config file > > > > Hi! > > > > On Thu, Sep 25, 2014 at 12:23 PM, Lucas Alvares Gomes < > > lucasago...@gmail.com> wrote: > > > >> Hi, > >> > >> Today we have hit the problem of having an outdated sample > >> configuration file again[1]. The problem of the sample generation is > >> that it picks up configuration from other projects/libs > >> (keystoneclient in that case) and this break the Ironic gate without > >> us doing anything. > >> > >> So, what you guys think about removing the test that compares the > >> configuration files and makes it no longer gate[2]? > >> > >> We already have a tox command to generate the sample configuration > >> file[3], so folks that needs it can generate it locally. > >> > >> Does anyone disagree? > >> > >> > > +1 to this, but I think we should document how to generate the sample > > config > > in our documentation (install guide?). > > > > -Dave > > -- > > David Shrewsbury (Shrews) > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > I tried this in Cinder a while back and was actually rather surprised by > the overwhelming push-back I received from the Operator community, and > whether I agreed with all of it or not, the last thing I want to do is > ignore the Operators that are actually standing up and maintaining what > we're building. > > Really at the end of the day this isn't really that big of a deal. It's > relatively easy to update the config in most of the projects "tox > -egenconfig" see my posting back in May [1]. For all the more often this > should happen I'm not sure why we can't have enough contributors that are > just pro-active enough to "fix it up" when they see it falls out of date. > > John > > [1]: http://lists.openstack.org/pipermail/openstack-dev/2014-May/036438.html +1 to what John just said. I know in Keystone we update the sample config (usually) whenever we notice it out of date. Often we ask developers making config changes to run `tox -esample_config` and re-upload their patch. If someone misses we (the cores) will do a patch that just updates the sample config along the way. Ideally we should have a check job that just reports the config is out of date (instead of blocking the review). The issue is the premise that there are 2 options: 1) Gate on the sample config being current 2) Have no sample config in the tree. The missing third option is the proactive approach (plus having something convenient like `tox -egenconfig` or `tox -eupdate_sample_config` to make it convenient to update the sample config) is the approach that covers both sides nicely. The Operators/deployers have the sample config in tree, the developers don’t get patched rejected in the gate because the sample config doesn’t match new options in an external library. I know a lot of operators and deployers appreciate the sample config being in-tree. —Morgan _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
