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@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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
