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.



OpenStack-dev mailing list

Reply via email to