Re: [openstack-dev] pep8 gating fails due to tools/config/check_uptodate.sh
On Wed, Mar 5, 2014 at 5:53 AM, Julien Danjou wrote: > On Tue, Mar 04 2014, Joe Gordon wrote: > >> So since tools/config/check_uptodate.sh is oslo code, I assumed this >> issue falls into the domain of oslo-incubator. >> >> Until this gets resolved nova is considering >> https://review.openstack.org/#/c/78028/ > > Removing tools/config/oslo.config.generator.rc would have a been a > better trade-off I think. > Perhaps, although the previous consensus in this thread seemed to be we generally don't want to include auto-generated files like config sample in git. Removing the check all together also solves the case where a patch in trunk adds a new config option and causes all subsequent patches in that repo to fail. > -- > Julien Danjou > // Free Software hacker > // http://julien.danjou.info ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] pep8 gating fails due to tools/config/check_uptodate.sh
On Tue, Mar 04 2014, Joe Gordon wrote: > So since tools/config/check_uptodate.sh is oslo code, I assumed this > issue falls into the domain of oslo-incubator. > > Until this gets resolved nova is considering > https://review.openstack.org/#/c/78028/ Removing tools/config/oslo.config.generator.rc would have a been a better trade-off I think. -- Julien Danjou // Free Software hacker // http://julien.danjou.info signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] pep8 gating fails due to tools/config/check_uptodate.sh
On 3/4/2014 4:34 PM, Joe Gordon wrote: So since tools/config/check_uptodate.sh is oslo code, I assumed this issue falls into the domain of oslo-incubator. Until this gets resolved nova is considering https://review.openstack.org/#/c/78028/ Keystone too: https://review.openstack.org/#/c/78030/ On Wed, Feb 5, 2014 at 9:21 AM, Daniel P. Berrange wrote: On Wed, Feb 05, 2014 at 11:56:35AM -0500, Doug Hellmann wrote: On Wed, Feb 5, 2014 at 11:40 AM, Chmouel Boudjnah wrote: On Wed, Feb 5, 2014 at 4:20 PM, Doug Hellmann wrote: Including the config file in either the developer documentation or the packaging build makes more sense. I'm still worried that adding it to the sdist generation means you would have to have a lot of tools installed just to make the sdist. However, we could I think that may slighty complicate more devstack with this, since we rely heavily on config samples to setup the services. Good point, we would need to add a step to generate a sample config for each app instead of just copying the one in the source repository. Which is what 'python setup.py build' for an app would take care of. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ 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 -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] pep8 gating fails due to tools/config/check_uptodate.sh
So since tools/config/check_uptodate.sh is oslo code, I assumed this issue falls into the domain of oslo-incubator. Until this gets resolved nova is considering https://review.openstack.org/#/c/78028/ On Wed, Feb 5, 2014 at 9:21 AM, Daniel P. Berrange wrote: > On Wed, Feb 05, 2014 at 11:56:35AM -0500, Doug Hellmann wrote: >> On Wed, Feb 5, 2014 at 11:40 AM, Chmouel Boudjnah >> wrote: >> >> > >> > On Wed, Feb 5, 2014 at 4:20 PM, Doug Hellmann > > > wrote: >> > >> >> Including the config file in either the developer documentation or the >> >> packaging build makes more sense. I'm still worried that adding it to the >> >> sdist generation means you would have to have a lot of tools installed >> >> just >> >> to make the sdist. However, we could >> > >> > >> > >> > I think that may slighty complicate more devstack with this, since we rely >> > heavily on config samples to setup the services. >> > >> >> Good point, we would need to add a step to generate a sample config for >> each app instead of just copying the one in the source repository. > > Which is what 'python setup.py build' for an app would take care of. > > Regards, > Daniel > -- > |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| > > ___ > 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] pep8 gating fails due to tools/config/check_uptodate.sh
On Wed, Feb 05, 2014 at 11:56:35AM -0500, Doug Hellmann wrote: > On Wed, Feb 5, 2014 at 11:40 AM, Chmouel Boudjnah wrote: > > > > > On Wed, Feb 5, 2014 at 4:20 PM, Doug Hellmann > > wrote: > > > >> Including the config file in either the developer documentation or the > >> packaging build makes more sense. I'm still worried that adding it to the > >> sdist generation means you would have to have a lot of tools installed just > >> to make the sdist. However, we could > > > > > > > > I think that may slighty complicate more devstack with this, since we rely > > heavily on config samples to setup the services. > > > > Good point, we would need to add a step to generate a sample config for > each app instead of just copying the one in the source repository. Which is what 'python setup.py build' for an app would take care of. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] pep8 gating fails due to tools/config/check_uptodate.sh
On Wed, Feb 05, 2014 at 05:40:13PM +0100, Chmouel Boudjnah wrote: > On Wed, Feb 5, 2014 at 4:20 PM, Doug Hellmann > wrote: > > > Including the config file in either the developer documentation or the > > packaging build makes more sense. I'm still worried that adding it to the > > sdist generation means you would have to have a lot of tools installed just > > to make the sdist. However, we could > > > > I think that may slighty complicate more devstack with this, since we rely > heavily on config samples to setup the services. devstack has to checkout nova and run its build + install steps, so it would have a full sample config available to use. So I don't think that generating config at build time would have any real negative impact on devstack overall. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] pep8 gating fails due to tools/config/check_uptodate.sh
On Wed, Feb 5, 2014 at 11:40 AM, Chmouel Boudjnah wrote: > > On Wed, Feb 5, 2014 at 4:20 PM, Doug Hellmann > wrote: > >> Including the config file in either the developer documentation or the >> packaging build makes more sense. I'm still worried that adding it to the >> sdist generation means you would have to have a lot of tools installed just >> to make the sdist. However, we could > > > > I think that may slighty complicate more devstack with this, since we rely > heavily on config samples to setup the services. > Good point, we would need to add a step to generate a sample config for each app instead of just copying the one in the source repository. Doug > > > Chmouel. > > > ___ > 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] pep8 gating fails due to tools/config/check_uptodate.sh
On Wed, Feb 5, 2014 at 4:20 PM, Doug Hellmann wrote: > Including the config file in either the developer documentation or the > packaging build makes more sense. I'm still worried that adding it to the > sdist generation means you would have to have a lot of tools installed just > to make the sdist. However, we could I think that may slighty complicate more devstack with this, since we rely heavily on config samples to setup the services. Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] pep8 gating fails due to tools/config/check_uptodate.sh
On Tue, Feb 4, 2014 at 6:39 PM, Joe Gordon wrote: > On Tue, Feb 4, 2014 at 8:19 AM, Sean Dague wrote: > > On 02/05/2014 12:37 AM, Mark McLoughlin wrote: > >> On Mon, 2014-01-13 at 16:49 +, Sahid Ferdjaoui wrote: > >>> Hello all, > >>> > >>> It looks 100% of the pep8 gate for nova is failing because of a bug > reported, > >>> we probably need to mark this as Critical. > >>> > >>>https://bugs.launchpad.net/nova/+bug/1268614 > >>> > >>> Ivan Melnikov has pushed a patchset waiting for review: > >>>https://review.openstack.org/#/c/66346/ > >>> > >>> > http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiRVJST1I6IEludm9jYXRpb25FcnJvcjogXFwnL2hvbWUvamVua2lucy93b3Jrc3BhY2UvZ2F0ZS1ub3ZhLXBlcDgvdG9vbHMvY29uZmlnL2NoZWNrX3VwdG9kYXRlLnNoXFwnXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjQzMjAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTM4OTYzMTQzMzQ4OSwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ== > >> > >> This just came up on #openstack-infra ... > >> > >> It's a general problem that is going to occur more frequently. > >> > >> Nova now includes config options from keystoneclient and oslo.messaging > >> in its sample config file. > >> > >> That means that as soon as a new option is added to either library, then > >> check_uptodate.sh will start failing. > >> > >> One option discussed is to remove the sample config files from source > >> control and have the sample be generated at build/packaging time. > >> > >> So long as we minimize the dependencies required to generate the sample > >> file, this should be manageable. > > > > The one big drawback here is that today you can point people to a git > > url, and they will then have a sample config file for Nova (or Tempest > > or whatever you are pointing them at). If this is removed, then we'll > > need / want some other way to make those samples easily available on the > > web, not only at release time. > > +1, to the idea of removing this auto-generated file from the repo. > > How about publishing these as part of the docs, we can put them in the > dev docs, so the nova options get published at: > > http://docs.openstack.org/developer/nova/ > > etc, or we can make sure the main docs are always updated etc. > I just talked with Anne, and she said the doc build now includes a Configuration Reference which is extracting the options and building nicely formatted tables. Given that, I don't think it adds much to include the config files as well. Including the config file in either the developer documentation or the packaging build makes more sense. I'm still worried that adding it to the sdist generation means you would have to have a lot of tools installed just to make the sdist. However, we could include a script with each app that will generate the sample file for that app. Anyone installing from source could run it to build their own file, and the distro packagers could run it as part of their build and include the output in their package. Doug > > > > > On a related point, It's slightly bothered me that we're allow libraries > > to define stanzas in our config files. It seems like a leaky abstraction > > that's only going to get worse over time as we graduate more of oslo, > > and the coupling gets even worse. > > > > Has anyone considered if it's possible to stop doing that, and have the > > libraries only provide an object model that takes args and instead leave > > config declaration to the instantiation points for those objects? > > Because having a nova.conf file that's 30% options coming from > > underlying libraries that are not really controlable in nova seems like > > a recipe for a headache. We already have a bunch of that issue today > > with changing 3rd party logging libraries in oslo, that mostly means to > > do that in nova we first just go and change the incubator, then sync the > > changes back. > > > > I do realize this would be a rather substantial shift from current > > approach, but current approach seems to be hitting a new complexity > > point that we're only just starting to feel the pain on. > > > > -Sean > > > > -- > > Sean Dague > > Samsung Research America > > s...@dague.net / sean.da...@samsung.com > > http://dague.net > > > > > > ___ > > 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 > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] pep8 gating fails due to tools/config/check_uptodate.sh
On Tue, Feb 4, 2014 at 8:19 AM, Sean Dague wrote: > On 02/05/2014 12:37 AM, Mark McLoughlin wrote: >> On Mon, 2014-01-13 at 16:49 +, Sahid Ferdjaoui wrote: >>> Hello all, >>> >>> It looks 100% of the pep8 gate for nova is failing because of a bug >>> reported, >>> we probably need to mark this as Critical. >>> >>>https://bugs.launchpad.net/nova/+bug/1268614 >>> >>> Ivan Melnikov has pushed a patchset waiting for review: >>>https://review.openstack.org/#/c/66346/ >>> >>> http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiRVJST1I6IEludm9jYXRpb25FcnJvcjogXFwnL2hvbWUvamVua2lucy93b3Jrc3BhY2UvZ2F0ZS1ub3ZhLXBlcDgvdG9vbHMvY29uZmlnL2NoZWNrX3VwdG9kYXRlLnNoXFwnXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjQzMjAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTM4OTYzMTQzMzQ4OSwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ== >> >> This just came up on #openstack-infra ... >> >> It's a general problem that is going to occur more frequently. >> >> Nova now includes config options from keystoneclient and oslo.messaging >> in its sample config file. >> >> That means that as soon as a new option is added to either library, then >> check_uptodate.sh will start failing. >> >> One option discussed is to remove the sample config files from source >> control and have the sample be generated at build/packaging time. >> >> So long as we minimize the dependencies required to generate the sample >> file, this should be manageable. > > The one big drawback here is that today you can point people to a git > url, and they will then have a sample config file for Nova (or Tempest > or whatever you are pointing them at). If this is removed, then we'll > need / want some other way to make those samples easily available on the > web, not only at release time. +1, to the idea of removing this auto-generated file from the repo. How about publishing these as part of the docs, we can put them in the dev docs, so the nova options get published at: http://docs.openstack.org/developer/nova/ etc, or we can make sure the main docs are always updated etc. > > On a related point, It's slightly bothered me that we're allow libraries > to define stanzas in our config files. It seems like a leaky abstraction > that's only going to get worse over time as we graduate more of oslo, > and the coupling gets even worse. > > Has anyone considered if it's possible to stop doing that, and have the > libraries only provide an object model that takes args and instead leave > config declaration to the instantiation points for those objects? > Because having a nova.conf file that's 30% options coming from > underlying libraries that are not really controlable in nova seems like > a recipe for a headache. We already have a bunch of that issue today > with changing 3rd party logging libraries in oslo, that mostly means to > do that in nova we first just go and change the incubator, then sync the > changes back. > > I do realize this would be a rather substantial shift from current > approach, but current approach seems to be hitting a new complexity > point that we're only just starting to feel the pain on. > > -Sean > > -- > Sean Dague > Samsung Research America > s...@dague.net / sean.da...@samsung.com > http://dague.net > > > ___ > 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] pep8 gating fails due to tools/config/check_uptodate.sh
On Tue, Feb 4, 2014 at 11:36 AM, Mark McLoughlin wrote: > On Wed, 2014-02-05 at 01:19 +0900, Sean Dague wrote: > > On 02/05/2014 12:37 AM, Mark McLoughlin wrote: > > > On Mon, 2014-01-13 at 16:49 +, Sahid Ferdjaoui wrote: > > >> Hello all, > > >> > > >> It looks 100% of the pep8 gate for nova is failing because of a bug > reported, > > >> we probably need to mark this as Critical. > > >> > > >>https://bugs.launchpad.net/nova/+bug/1268614 > > >> > > >> Ivan Melnikov has pushed a patchset waiting for review: > > >>https://review.openstack.org/#/c/66346/ > > >> > > >> > http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiRVJST1I6IEludm9jYXRpb25FcnJvcjogXFwnL2hvbWUvamVua2lucy93b3Jrc3BhY2UvZ2F0ZS1ub3ZhLXBlcDgvdG9vbHMvY29uZmlnL2NoZWNrX3VwdG9kYXRlLnNoXFwnXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjQzMjAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTM4OTYzMTQzMzQ4OSwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ== > > > > > > This just came up on #openstack-infra ... > > > > > > It's a general problem that is going to occur more frequently. > > > > > > Nova now includes config options from keystoneclient and oslo.messaging > > > in its sample config file. > > > > > > That means that as soon as a new option is added to either library, > then > > > check_uptodate.sh will start failing. > > > > > > One option discussed is to remove the sample config files from source > > > control and have the sample be generated at build/packaging time. > > > > > > So long as we minimize the dependencies required to generate the sample > > > file, this should be manageable. > > > > The one big drawback here is that today you can point people to a git > > url, and they will then have a sample config file for Nova (or Tempest > > or whatever you are pointing them at). If this is removed, then we'll > > need / want some other way to make those samples easily available on the > > web, not only at release time. > > I think that's best addressed by automatically publishing to somewhere > other than git.openstack.org. AFAIR there's already been a bunch of work > done around automatically pulling config options into the docs. > > > On a related point, It's slightly bothered me that we're allow libraries > > to define stanzas in our config files. It seems like a leaky abstraction > > It is a little unusual, yes. > > > that's only going to get worse over time as we graduate more of oslo, > > and the coupling gets even worse. > > Worse in what respect? > > > Has anyone considered if it's possible to stop doing that, and have the > > libraries only provide an object model that takes args and instead leave > > config declaration to the instantiation points for those objects? > > I think that would result in useless duplication (of those declarations) > and leave us open to projects having different config file options for > the same things. > > > Because having a nova.conf file that's 30% options coming from > > underlying libraries that are not really controlable in nova seems like > > a recipe for a headache. > > Why? > > > We already have a bunch of that issue today > > with changing 3rd party logging libraries in oslo, that mostly means to > > do that in nova we first just go and change the incubator, then sync the > > changes back. > > That's a different issue - if we had a properly abstracted logging API, > we could commit to future API compat and publish an oslo.logging > library. > Roman's patch to make the ContextFormatter do most of the work [1] instead of having adapters is the first step to making oslo.logging be a library for configuring logging so that apps and libraries can use python's stdlib logging module to actually get the logger objects. [1] https://review.openstack.org/#/c/63782/ Doug > > The syncing pain you describe would go away, and the proper abstraction > would mean the things that Nova needs to control would be under Nova's > control. > > > I do realize this would be a rather substantial shift from current > > approach, but current approach seems to be hitting a new complexity > > point that we're only just starting to feel the pain on. > > The issue at hand is that we've discovered that checking an > autogenerated file into git causes issues ... hardly the first time > we've learned that lesson. > > Mark. > > > ___ > 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] pep8 gating fails due to tools/config/check_uptodate.sh
On Tue, Feb 04, 2014 at 04:36:05PM +, Mark McLoughlin wrote: > On Wed, 2014-02-05 at 01:19 +0900, Sean Dague wrote: > > On 02/05/2014 12:37 AM, Mark McLoughlin wrote: > > I do realize this would be a rather substantial shift from current > > approach, but current approach seems to be hitting a new complexity > > point that we're only just starting to feel the pain on. > > The issue at hand is that we've discovered that checking an > autogenerated file into git causes issues ... hardly the first time > we've learned that lesson. It isn't the first time that the nova.conf.sample has caused us pain either. I've lost count of the number of times I've -1'd reviews because they messed up the config file during a rebase merge, or forgotten to update it, or had the re-generation tools fail silently and add a -1000 line diff that deletes the entire config file content. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] pep8 gating fails due to tools/config/check_uptodate.sh
On Wed, 2014-02-05 at 01:19 +0900, Sean Dague wrote: > On 02/05/2014 12:37 AM, Mark McLoughlin wrote: > > On Mon, 2014-01-13 at 16:49 +, Sahid Ferdjaoui wrote: > >> Hello all, > >> > >> It looks 100% of the pep8 gate for nova is failing because of a bug > >> reported, > >> we probably need to mark this as Critical. > >> > >>https://bugs.launchpad.net/nova/+bug/1268614 > >> > >> Ivan Melnikov has pushed a patchset waiting for review: > >>https://review.openstack.org/#/c/66346/ > >> > >> http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiRVJST1I6IEludm9jYXRpb25FcnJvcjogXFwnL2hvbWUvamVua2lucy93b3Jrc3BhY2UvZ2F0ZS1ub3ZhLXBlcDgvdG9vbHMvY29uZmlnL2NoZWNrX3VwdG9kYXRlLnNoXFwnXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjQzMjAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTM4OTYzMTQzMzQ4OSwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ== > > > > This just came up on #openstack-infra ... > > > > It's a general problem that is going to occur more frequently. > > > > Nova now includes config options from keystoneclient and oslo.messaging > > in its sample config file. > > > > That means that as soon as a new option is added to either library, then > > check_uptodate.sh will start failing. > > > > One option discussed is to remove the sample config files from source > > control and have the sample be generated at build/packaging time. > > > > So long as we minimize the dependencies required to generate the sample > > file, this should be manageable. > > The one big drawback here is that today you can point people to a git > url, and they will then have a sample config file for Nova (or Tempest > or whatever you are pointing them at). If this is removed, then we'll > need / want some other way to make those samples easily available on the > web, not only at release time. I think that's best addressed by automatically publishing to somewhere other than git.openstack.org. AFAIR there's already been a bunch of work done around automatically pulling config options into the docs. > On a related point, It's slightly bothered me that we're allow libraries > to define stanzas in our config files. It seems like a leaky abstraction It is a little unusual, yes. > that's only going to get worse over time as we graduate more of oslo, > and the coupling gets even worse. Worse in what respect? > Has anyone considered if it's possible to stop doing that, and have the > libraries only provide an object model that takes args and instead leave > config declaration to the instantiation points for those objects? I think that would result in useless duplication (of those declarations) and leave us open to projects having different config file options for the same things. > Because having a nova.conf file that's 30% options coming from > underlying libraries that are not really controlable in nova seems like > a recipe for a headache. Why? > We already have a bunch of that issue today > with changing 3rd party logging libraries in oslo, that mostly means to > do that in nova we first just go and change the incubator, then sync the > changes back. That's a different issue - if we had a properly abstracted logging API, we could commit to future API compat and publish an oslo.logging library. The syncing pain you describe would go away, and the proper abstraction would mean the things that Nova needs to control would be under Nova's control. > I do realize this would be a rather substantial shift from current > approach, but current approach seems to be hitting a new complexity > point that we're only just starting to feel the pain on. The issue at hand is that we've discovered that checking an autogenerated file into git causes issues ... hardly the first time we've learned that lesson. Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] pep8 gating fails due to tools/config/check_uptodate.sh
On 02/05/2014 12:37 AM, Mark McLoughlin wrote: > On Mon, 2014-01-13 at 16:49 +, Sahid Ferdjaoui wrote: >> Hello all, >> >> It looks 100% of the pep8 gate for nova is failing because of a bug >> reported, >> we probably need to mark this as Critical. >> >>https://bugs.launchpad.net/nova/+bug/1268614 >> >> Ivan Melnikov has pushed a patchset waiting for review: >>https://review.openstack.org/#/c/66346/ >> >> http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiRVJST1I6IEludm9jYXRpb25FcnJvcjogXFwnL2hvbWUvamVua2lucy93b3Jrc3BhY2UvZ2F0ZS1ub3ZhLXBlcDgvdG9vbHMvY29uZmlnL2NoZWNrX3VwdG9kYXRlLnNoXFwnXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjQzMjAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTM4OTYzMTQzMzQ4OSwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ== > > This just came up on #openstack-infra ... > > It's a general problem that is going to occur more frequently. > > Nova now includes config options from keystoneclient and oslo.messaging > in its sample config file. > > That means that as soon as a new option is added to either library, then > check_uptodate.sh will start failing. > > One option discussed is to remove the sample config files from source > control and have the sample be generated at build/packaging time. > > So long as we minimize the dependencies required to generate the sample > file, this should be manageable. The one big drawback here is that today you can point people to a git url, and they will then have a sample config file for Nova (or Tempest or whatever you are pointing them at). If this is removed, then we'll need / want some other way to make those samples easily available on the web, not only at release time. On a related point, It's slightly bothered me that we're allow libraries to define stanzas in our config files. It seems like a leaky abstraction that's only going to get worse over time as we graduate more of oslo, and the coupling gets even worse. Has anyone considered if it's possible to stop doing that, and have the libraries only provide an object model that takes args and instead leave config declaration to the instantiation points for those objects? Because having a nova.conf file that's 30% options coming from underlying libraries that are not really controlable in nova seems like a recipe for a headache. We already have a bunch of that issue today with changing 3rd party logging libraries in oslo, that mostly means to do that in nova we first just go and change the incubator, then sync the changes back. I do realize this would be a rather substantial shift from current approach, but current approach seems to be hitting a new complexity point that we're only just starting to feel the pain on. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] pep8 gating fails due to tools/config/check_uptodate.sh
On Mon, 2014-01-13 at 16:49 +, Sahid Ferdjaoui wrote: > Hello all, > > It looks 100% of the pep8 gate for nova is failing because of a bug reported, > we probably need to mark this as Critical. > >https://bugs.launchpad.net/nova/+bug/1268614 > > Ivan Melnikov has pushed a patchset waiting for review: >https://review.openstack.org/#/c/66346/ > > http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiRVJST1I6IEludm9jYXRpb25FcnJvcjogXFwnL2hvbWUvamVua2lucy93b3Jrc3BhY2UvZ2F0ZS1ub3ZhLXBlcDgvdG9vbHMvY29uZmlnL2NoZWNrX3VwdG9kYXRlLnNoXFwnXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjQzMjAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTM4OTYzMTQzMzQ4OSwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ== This just came up on #openstack-infra ... It's a general problem that is going to occur more frequently. Nova now includes config options from keystoneclient and oslo.messaging in its sample config file. That means that as soon as a new option is added to either library, then check_uptodate.sh will start failing. One option discussed is to remove the sample config files from source control and have the sample be generated at build/packaging time. So long as we minimize the dependencies required to generate the sample file, this should be manageable. Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
