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

Doug Hellmann doug.hellmann at dreamhost.com
Wed Feb 5 15:20:57 UTC 2014


On Tue, Feb 4, 2014 at 6:39 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:

> On Tue, Feb 4, 2014 at 8:19 AM, Sean Dague <sean at 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.
>

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
> > sean at dague.net / sean.dague at samsung.com
> > http://dague.net
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> 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/20140205/5f26abf6/attachment-0001.html>


More information about the OpenStack-dev mailing list