[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[goals][upgrade-checkers] Retrospective

On 4/26/19 3:59 AM, Mark Goddard wrote:
>      > 3. For the warnings, would you recommend a -Werror style argument
>     that
>      > optionally flags up warnings as errors? Reporting non-fatal
>     errors is
>      > quite difficult in Ansible.
>     OSA fails on any return codes that aren't 0 (success) or 1 (warning).
>     It's hard to say when warning should be considered an error really.
>     When
>     writing these checks I think of warning as a case where you might be OK
>     but we don't really know for sure, so it can aid in debugging
>     upgrade-related issues after the fact but might not necessarily mean
>     you
>     shouldn't upgrade. mnaser has brought up the idea in the past of making
>     the output more machine readable so tooling could pick and choose which
>     things it considers to be a failure (assuming the return code was 1).
>     That's an interesting idea but one I haven't put a lot of thought into.
>     It might be as simple as outputting a unique code per check per
>     project,
>     sort of like the error code concept in the API guidelines [3] which the
>     placement project is using [4].
> Machine readable would be nice. Perhaps there's something we could do to 
> generate a report of the combined results.

Note that there's a todo[0] in the oslo.upgradecheck code to switch to 
cliff for the output. That would allow us to easily output in 
machine-readable formats.