Last week we have successfully released Icinga for Windows v1.9.0 with plenty of changes regarding on how modules work. While customers and users were adopting the new versions quickly, in some cases it turned out that certain plugins did no longer work as expected.
This was especially true for Hyper-V and Cluster Plugins.
What Happened?
While the new module isolation worked perfectly in most cases, it worked a little too well regarding Hyper-V and Cluster plugins. Both plugins rely on the Basic Plugins, which provides some metadata regarding service states and other information which are declared there, because they are used for disk and service monitoring.
Because of the nature of PowerShell modules, the new isolation ensured that other modules were never loaded. This means, while a Hyper-V plugin were executed, the Basic plugin module was never loaded and therefor crucial metadata information were missing to translate certain information. Users who are using the REST-Api or JEA were not affected by this, because the nature of these solutions always ensures that every single Icinga for Windows component is loaded anyway. Therefore, only users running without JEA or the REST-Api were affected.
Solution – Imports!
To fix this we released Icinga for Windows v1.9.1 today, which now ensures that every single Icinga for Windows component is loaded, once the Framework itself is being loaded. Therefore, an Icinga for Windows environment will have all modules and components initialized and made available within a PowerShell session.
This ensures that all publicly available Cmdlets, Variables, Aliases and Functions for all installed Icinga for Windows components are usable, while the new introduced module isolation is still in effect and ensures integrity between components and prevents unwanted overrides.
In case you run into this problem, please update the Icinga PowerShell Framework to v1.9.1.
We are sorry for any inconvenience this may have caused and wish everyone a happy week and weekend in advance!
