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

Sean Dague sean at dague.net
Tue Feb 4 16:19:13 UTC 2014


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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140205/4235d422/attachment.pgp>


More information about the OpenStack-dev mailing list