On Tue, Feb 4, 2014 at 11:36 AM, Mark McLoughlin <[email protected]> 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 +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. > > 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
