Open Stack

On Thu, Sep 25, 2014 at 7:13 PM, Tom Fifield <tom at openstack.org> wrote:
> On 26/09/14 03:35, Morgan Fainberg wrote:
>> -----Original Message-----
>> From: John Griffith <john.griffith8 at gmail.com>
>> Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>>
>> Date: September 25, 2014 at 12:27:52
>> To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at 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.kulkarni at 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.dave at 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 <
>>>> lucasagomes at 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 at 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