The namespace support in 2.10 caused a regression with the registered global scope being evaluated for API permissions with filters. This release fixes the problem, next to a problem with Windows packages not fully starting up. There’s also a fixed oversight with not setting a default environment constant. This affects setups checking the SNI header in external load balancers.
v2.10.1 also fixes a problem with application reload and missing event states in large scale environments.
Our friends from the Max-Planck-Institut for Marine Mikrobiologie kindly sponsored that acknowledgement notifications are now sent only to users which have been notified about a problem before – thanks a lot. Another sponsor asked for more child options for the ScheduledDowntime which are now released in 2.10.
2.10 also brings support for namespaces and allows us to keep the “globals” namespace clean. In addition to that, user-defined namespaces are possible and can be imported into the global namespace too. Read more about this feature here. An additional DSL feature is the support for references. You’ll also find new fine granular path constants in this release, e.g. ConfigDir instead of SysconfDir + “/icinga2”. The old constants are still intact but deprecated.
As promised in the 2.9.2 release post, we’ve been debugging TLS connection handling with many threads and TLS timeouts in large scale environments. This release adds a dynamic thread connection pool for both, cluster messages and HTTP requests. With the performance boost granted, we’ve also lowered the cluster reconnect interval from 60 to 10 seconds. This ensures that configuration deployments triggering a reload don’t leave clients behind.
Our first Icinga meetup in Salzburg, Austria is happening this week. Join fellow community members :) OSMC is near, just one month to go …. meet Jan-Piet on MQTT, Claudio as a first-time speaker on container monitoring, Nicolai with infrastructure visualization and Carsten with his “Einhornmagie” :-)
Icinga 2 v2.9 introduced performance related changes inside the configuration compilation and activation order. This was to ensure a) no unwanted notifications b) use available CPU resources to speed up the overall validation process. These changes had a bad effect on configuration depending on a specific activation order, and slowed it down with many config objects of a specific type. The Icinga Director depends on get_host() being called in service objects to support specific service set overrides. In case you’re having trouble here, v2.9.2 is for you.
Under the hood, Icinga 2 uses many constants and reserved keywords, e.g. “Critical” or “Zone” which are respected by the config parser and compiler. This sometimes leads to errors when users accidentally override such things, or re-define their own global constants. v2.10 introduces namespaces for this purpose, and ensures that such accidents won’t happen anymore.
What exactly is a namespace?
Think of a defined “room” for variables, functions, etc. which can be defined similar to constants. They are isolated from other namespaces and must be loaded by the user/developer. Namespaces need a defined name – we prefer to use a capitalized string, e.g. “MyNamespace”. This helps to immediately qualify this as customization when reading the configuration.
Icinga 2 v2.10 uses namespaces which are registered and loaded by default. In order to test this, open the debug console on a test VM which has the snapshot packages installed. Fetch the keys in global namespace “globals” first.