instead of marking the logs that we think should be clean, mark
the ones we think should be dirty. This means no new services can
come in with unclean logs.
remove the whitelist data, as that's currently obsolete, we'll
remove the code for it later.
Change-Id: I4b15c932b78f54ec371aa67c7b4e8248b3f9c0eb
These log errors have hit the large ops jobs several times. There is one
in ceilometer acentral and one in nova conductor.
Change-Id: Idc30110085e95c615958fc5f90e86417855e6d7a
According to John Dickinson:
"This isn't an error. It's logged at an error level because it may hint
at other problems, and it's something an operator needs to know about,
but it is not an unhandled failure condition. (Think of it similarly how
in swift a server being down is an "error", but it's something that
swift seamlessly works around.)"
Closes-Bug: #1260894
Change-Id: I41e55c5e34ee214727fbbd7b9daa1f6ea9bf8050
It looks like the whitelist for the DHCP agent is added
twice. This looks like a genuine typo, and if it isn't
there is clearly something wrong! There's no good reason
for duplicating the list of whitelisted errors.
Change-Id: Ib94f60e8aa3ce1b0a6e28d9051da0124d403bf27
The script will take a directory or url containing log files.
For now all non-whitelisted errors will be dumped to the console but
the script will always return success. Once we are convinced it is reliable
enough we can change it to fail on non-whitelisted errors.
Partially implements blueprint fail-gate-on-log-errors
Change-Id: I30b0eee1055f47aaad7984d886c739ccf5aa6186