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

[Alexander Wirt]

Bernhard Schmidt schrieb am Freitag, den 22. Juni 2012:

> 
> >>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.
Given my available time until freeze, its already fucking cold.

Alex

-- 
Alexander Wirt, formorer at formorer.de 
CC99 2DDD D39E 75B0 B0AA  B25C D35B BC99 BC7D 020A