On Thu, Sep 25, 2014 at 7:13 PM, Tom Fifield <t...@openstack.org> wrote: > 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) >> <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. > > Just confirming this is definitely the case.
Thanks, all. I agree with the points made here and really appreciate the feedback from other projects and operators. I've proposed a change to Ironic to - remove check_uptodate from our pep8 test env - updated the "genconfig" target to make it even easier to build the sample config file https://review.openstack.org/124919 Cheers, Devananda _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
