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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
