[openstack-dev] pep8 gating fails due to tools/config/check_uptodate.sh

Doug Hellmann doug.hellmann at dreamhost.com
Tue Feb 4 18:44:05 UTC 2014


On Tue, Feb 4, 2014 at 11:36 AM, Mark McLoughlin <markmc at redhat.com> 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140204/96f2aace/attachment.html>


More information about the OpenStack-dev mailing list