Comment # 2 on bug 1172259 from William Brown

(In reply to Lars Vogdt from comment #1)
> Sounds interesting, but I have to admit that I haven't worked with
> transactional servers, yet. So I need some help and/or a bit more specific
> specs to implement this.
> 
> Looking at this from a user story view to understand your request a bit
> better:
> 
> If a user runs 
>   'check_zypper --check_transactional_update'
> what is the expected output on a transactional server?
> 
> 1) everything ok (no updates, no problems)
> 2) pending updates -> warning state
> 3) pending updates, they were installed on the local machine - but rolled
> back because of problems. -> warning? ok?

I think this sounds correct, yes. We need to be able to see when an update was
attempted but was rolled back, because what ends up occurring is the server
"forever" attempts to update but never succeeds due to some outstanding issue. 

> 
> 
> 1+2 are covered already.
> 
> For 3, I would currently suggest the use of the 'whitelist' feature of
> check_zypper, which allows to ignore certain packages or even patches by
> mentioning them in a file.
> 
> See 'check_zypper --help' or have a look at
> https://github.com/lrupp/monitoring-plugins-zypper for additional details.
> 
> -i, --ignore <file>
>       Ignore patches/packages that are mentioned in <file>
> 
>       Examples:
>       patch:libtiff-devel
>       # comment
>       package:libtiff3
>       package:libtiff-devel
>       # comment
>       whitelist:aaa_base
>       # comment
>       local_package:mypackage
> 
> 
> I'm not sure if the list could be somehow automatically generated from a
> transactional machine that had been rolled back (IMHO this would need log
> file parsing?). I'm open for suggestions here... Any ideas?

I think you know more about this than I do :) I am not sure how to do this.
Perhaps tkukuk or rbrown know more?