Have you tested v2.12rc1+v2.8rc1?

Dear early adopters,

usually we publish release candidates of our projects, wait for them to be tested by others than us too, fix bugs (if any) and release the final version.

This time we also released Icinga v2.12.0-rc1 Icinga Web v2.8.0-rc1 and Icinga DB v1.0-rc1. But I’m afraid we can’t rely on the usual amount of external testers per time unit as many of you unfortunately have trouble with COVID19. Just to be sure we ask you explicitly:

Have you already tested those new release candidates?


Is there a vagrant box ready to test it? iam too busy to do a full setup right now.

1 Like

Hi, at the moment we are using the time to do things what we put off for a long time. So no

I would like to test an update from 2.11.{2,3} to prepare my ansible rolls for a new release.

Especially updates with changes in the system architecture lead to significant errors, which should be documented and corrected if possible.

However, I don’t have the time to do research in this direction.

Which changes and which errors are you talking about?

So far, a database (mysql, postgresql) is the end point of the IDO.
This is now replaced by the IcingaDB.
As I understood it so far, also without replacement.
I maintain some installations that keep a lot of data in their database.
Without testing, errors will occur here.
This is what my experience and gut tells me.

I might not get it correctly but I think you fear that we’re dropping support the IDO completely.
Be assured, that is not true. For the moment, this is just a release candidate so nothing will happen really besides that we want to get Icinga DB related feedback.
Once we have a final release with all missing features, PostgreSQL support and migration features ready, we will deprecate the IDO and shift towards the Icinga DB as main backend.
Though that means that we don’t drop the support.
We know that it takes time until the Icinga DB is adopted (maybe even up to one to two years) and we won’t drop the IDO until it is comfortable to do so.

And maybe that’s also a missing piece: Both the IDO and Icinga DB are separate features and run independent from each other. Also in Icinga Web. So you either run both or just the IDO or Icinga DB.


Thanks for the clarification.
I have not been able to find such a clear statement anywhere else.

1 Like


I already did a quick test installation, but not tested in depth yet. I already reported two issues which I found during the test.

I’d like to see the following tests:

  • IcingaDB in a HA enabled environment
  • Icinga v2.12.0 master with older versions
    • Icinga v2.11.x as satellite
    • Icinga v2.10.x as agent

Best regards

1 Like

Already testing it, once i get more results i’ll update Icinga2 at large scale topic for big environments.

Also i’m missing documentation about HighAvailability setup for each deamon in Icinga 2.12rc (icinga-core feature icingadb / redis / icingadb). if i have 2 masters i’m not sure by what principle they are updating redis(i have local redis without ha on each master), both in parallel or only the primary master.

In https://icinga.com/docs/icingadb/latest/doc/01-About/ following statement not documented:

Icinga DB also supports reading from multiple environments and writing into a single MySQL instance.

It would be nice to get little bit more info about this feature


I have only spent a few hours with a minimal test-setup and an update to version r2.12.0-rc1-1

I am not sure if this is worth to be mentioned, but after the update some checks didn’t work as before, all for the same reason as shown below.

I do not consider this as a bug.
This seems to be more a change in behaviour.

I will try do describe the change:
I have a script which has an optional argument, let’s say: -s
If the value passed with -s is not an empty string, it will be used by the script, otherwise ignored.
If -s is passed to the script, it has to contain a value, otherwise the script will complain and exit.

Here the lines of the corresponding checkcommand:

    "-s" = {
          value = "$http_searchstring$"
          required = false

Accidently, -s was always passed the script.

Here is the difference in the behaviour:

Previously the following was executed

/usr/lib/nagios/plugins/check_http_statuscode.sh' '-H' '' '-s' ''

With r2.12.0-rc1-1 the following happens:

/usr/lib/nagios/plugins/check_http_statuscode.sh' '-H' '' '-s'

The slight difference in the 2nd example are the missing single quotes at the end.
So the script fails.