On 26/09/14 03:35, Morgan Fainberg wrote: > -----Original Message----- > From: John Griffith <john.griffi...@gmail.com> > Reply: OpenStack Development Mailing List (not for usage questions) > <firstname.lastname@example.org>> > Date: September 25, 2014 at 12:27:52 > To: OpenStack Development Mailing List (not for usage questions) > <email@example.com>> > 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. 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? >>>> >>>> We already have a tox command to generate the sample configuration >>>> file, 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 >>> OpenStackfirstname.lastname@example.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 . 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 >> >> : 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.
Just confirming this is definitely the case. Regards, Tom _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev