On Tue, Feb 4, 2014 at 8:19 AM, Sean Dague <s...@dague.net> wrote: > On 02/05/2014 12:37 AM, Mark McLoughlin wrote: >> On Mon, 2014-01-13 at 16:49 +0000, 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