Re: [openstack-dev] [Ironic] Get rid of the sample config file
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
[openstack-dev] [Ironic] Get rid of the sample config file
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] https://review.openstack.org/#/c/124090/ [2] https://github.com/openstack/ironic/blob/master/tox.ini#L23 [3] https://github.com/openstack/ironic/blob/master/tox.ini#L32-L34 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Get rid of the sample config file
On 09/25/2014 06:23 PM, Lucas Alvares Gomes 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? It's a pity we won't have sample config by default, but I guess it can't be helped. +1 from me. [1] https://review.openstack.org/#/c/124090/ [2] https://github.com/openstack/ironic/blob/master/tox.ini#L23 [3] https://github.com/openstack/ironic/blob/master/tox.ini#L32-L34 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Get rid of the sample config file
On Sep 25, 2014, at 9:23 AM, 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. +1 In a perfect world, one would be generated and put somewhere for easy access without a development environment setup. However I think the impact from having this config file break pep8 non-interactively is important enough to do it now and worry about generating one for docs later. :) - Jay Faulkner Does anyone disagree? [1] https://review.openstack.org/#/c/124090/ [2] https://github.com/openstack/ironic/blob/master/tox.ini#L23 [3] https://github.com/openstack/ironic/blob/master/tox.ini#L32-L34 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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
Re: [openstack-dev] [Ironic] Get rid of the sample config file
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.commailto: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
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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Get rid of the sample config file
-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
Re: [openstack-dev] [Ironic] Get rid of the sample config file
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. Regards, Tom ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
