upstream/icinga-powershell-framework
1
0
Fork 0
mirror of https://github.com/Icinga/icinga-powershell-framework.git synced 2025-12-21 07:10:15 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions
icinga-powershell-framework/doc/30-upgrading-framework.md
Lord Hepipud eae48d222e Adds upgrading notes for plugins and kickstart
2020-11-20 12:36:27 +01:00

3.7 KiB
Raw Blame History

Upgrading Icinga PowerShell Framework

Upgrading Icinga PowerShell Framework is usually quite straightforward.

Specific version upgrades are described below. Please note that version updates are incremental.

Upgrading to v1.3.0 (pending)

Breaking Changes

Components

Icinga PowerShell Kickstart

Upgrading to v1.2.0 (2020-08-28)

Behavior changes

Changes on check command execution

Breaking Change/Important Note: Check Command configuration generated by Icinga for Windows 1.2.0 require Icinga for Windows 1.2.0 or later deployed on all systems, otherwise you will run into issues with an unknown command Exit-IcingaPluginNotInstalled error.

As mentioned in #95 we should make sure that in case the Framework itself is not installed on a system or plugins are missing the user is informed about this. We do how ever not intend to print huge stack traces of PowerShell errors into the console, but inform in a minimalistic way about this.

For this reason we will cover with a Try-Catch statement if the Use-Icinga command is executed and return a proper message and error code on failures. In addition we will now check of a plugin is installed before the execution of it, ensuring that in case it is not present on the system we receive an Unknown message that a certain plugin is not installed or present.

To apply this new behaviour you will have to generate a new check command basket file for the Icinga Director by using Get-IcingaCheckCommandConfig and import the new version. Once imported and deployed, the new handling will be in effect.

Upgrading to v1.1.0 (2020-06-02)

Behavior changes

Changes on -AcceptConnections

The behaviour on how the -AcceptConnections argument of the setup wizard is working has been fixed. Prior to version v1.1.0 the opposite effect took place.

Previous behaviour:

Setting -AcceptConnections 1 would continue with having to configure endpoint configurations while -AcceptConnections 0 would open the Windows Firewall for incoming connections

New behavior:

Setting -AcceptConnections 1 will only configure the Agent to wait for parent node(s) and open the Windows firewall for incoming traffic. Using -AcceptConnections 0 is now working properly by letting the Agent establish the connection to the parent node(s)

New wizard argument -ConvertEndpointIPConfig

With v1.1.0 a new argument is added to the wizard which will prompt a question if hostnames or FQDN for connection data from the Agent to the parent node(s) shall be converted to IP addresses. If you are unsure of the result, you can manually add -ConvertEndpointIPConfig 0 to your finished configuration string or scripts or answer the question with no to keep the current behavour.

By using -ConvertEndpointIPConfig 1 or answering the wizard question with yes, all endpoint configuration data for your parent node(s) are resolved from hostname/FQDN to IP Addresses if possible

Renames 'latest' Agent version

The value latest for the Icinga Agent version argument has been deprecated and replaced by release. For now the value is changed for you, following with a deprecation warning. Please update all your Icinga Director and script configuration.