Open Stack

On 1/13/2014 10:49 AM, 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==
>
>
> s.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

This broke us (nova) again today after python-keystoneclient-0.5.0 was 
released with a new config option. Joe Gordon pushed the patch to fix 
nova [1] so everyone will need to recheck their patches again once that 
merges.

This is going to be a continuing problem when external libs that nova 
pulls config options from get released, which now also includes 
oslo.messaging.

Ben Nemec floated some ideas in the previous bug [2]. I'll restate them 
here for discussion:

1) Set up a Jenkins job that triggers on keystoneclient releases to 
check whether it changed their config options and automatically propose 
an update to the other projects. I expect this could work like the 
requirements sync job.

2) Move the keystoneclient config back to a separate file and don't 
automatically generate it. This will likely result in it getting out of 
date again though. I assume that's why we started including 
keystoneclient directly in the generated config.

Joe also had an idea that we keep/generate a vanilla nova.conf.sample 
that only includes options from the nova tree itself which the 
check_uptodate script can check against, not the one generated under 
etc/nova/ which has the external lib options in it.  Then we can still 
get the generated nova.conf.sample that gets packaged by setup.cfg with 
the external lib options but not gate on it when those external packages 
are updated. (Joe, please correct my summary of your idea if it's wrong).

I was also thinking of something similar which could maybe just be done 
in memory where the check tool keeps track of the external config 
options and when validating the generated nova.conf.sample it ignores 
any 'failures' if they are in the list of external options.

Anyway, no matter how we fix it, we need to fix it, so let's weigh the 
pros and cons of the various options since this is worse than a race 
condition that breaks the gate, it just simply breaks and blocks 
everything until fixed.

[1] https://review.openstack.org/#/c/70891/
[2] https://bugs.launchpad.net/nova/+bug/1268614/comments/15

-- 

Thanks,

Matt Riedemann