[Pkg-nagios-devel] Bug#678396: Bug#678396: Bug#678396: check-mk: New upstream version 1.2.0p1 available

[Bernhard Schmidt]

>> cb13c56 Imported Upstream version 1.2.0p1 5389660 update defaults
>> for check-mk 1.2.0p1 13ff0f6 update .install files for new
>> location, install smart plugin (really fixes #649677) 561badc Run
>> automation calls as root to fix interaction with systemd 8f173d9
>> poor-man's-job to convert to quilt instead of dpatch (NOT
>> 3.0(quilt) source format)
>
> does that patchset include the possibility to autoconvert all hr_fs
> filesystem rrds from single to multiple? i know that this only
> happens when you are using check_mk with pnp4nagios but since
> upstream puts pnp4nagios into its design picture, i think it's worth
>  a thought.
>
> see my notes here
> https://wiki.icinga.org/display/howtos/check_mk+upgrade#check_mkupgrade-PerfdataFilesystemTrends
>
>
>
I think this default should be changed in pnp4nagios and migration be
assisted in that package. check-mk should probably get a NEWS.Debian
pointing to instructions.

> probably this is more of a check_mk with pnp4nagios problem, but feel
> free to share your thoughts on that transition as well.

check-mk has historically been a pain in the ass for new releases, and I
don't think this can all be solved in packaging. So I think the only
thing we can do (safe of pnp4nagios automigrating everything to
MULTIPLE) is to warn the user and document the known issues, i.e. on a
wiki page like yours.

> we ran into the mentioned perfdata changes in combination with
> pnp4nagios, but also other compatibility breaking changes which were
> partly resolvable by proper packages and partly needed man days of
> manual investigation. hearing from check_mk devs, i quote, "
> dnsmichi: normal users have support contracts", is pretty "awesome"
> for calling their releases "stable" *sigh*

Totally agreed, but that will not get better by sticking at earlier
releases :-)

> since the wheezy freeze is NOW in progress, i don't think you should
> hurry putting that into the current wheezy release target. i would
> rather go with sanity and help make the wheezy-backports package
> ready, and point users over there. even make rrd transition work -
> that can be scripted if needed. if you happen to have packages within
> the next months for that, i'd be happy to help test and fix possible
> regressions on my test boxes (icinga only ofc) to keep my production
> boxes safe when i do a d-u.

I disagree here. 1.1.12p7 is outdated now, and we haven't even begun 
freezing. From my POV, apart from the changed perfdata which is a 
problem with almost every RRD upgrading a standard 1.1.12p7 to 1.2.0p1 
should be relatively straightforward. The pain starts when you try to 
start using the new features of the WebGUI, but that's not a packaging 
issue. It's in the twisted logic of the applicaton.

IMO the MULTIPLE migration should be done by pnp4nagios.

Bernhard