ID: 5827
Title: Background jobs: fixed race condition where current job state was not available
Component: WATO
Level: 1
Class: Bug fix
Version: 1.6.0i1
ID: 5826
Title: mrpe: Fixed broken option "Append age to output"
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 1.6.0i1
Setting this option in the agent bakery, causing the mrpe check not to return any output.
ID: 5825
Title: Fixed broken sync of personal user settings information to slave sites
Component: Multisite
Level: 1
Class: Bug fix
Version: 1.6.0i1
Werk 6053 broke synchronisation of personal user settings to slave sites. This has been fixed.
Note: The personal user settings are also synced during "Activate changes".
So they are synced after all - just a bit delayed.
ID: 6013
Title: Correctly ignore downtimes for vanished hosts/services.
Component: Core & setup
Level: 1
Class: Bug fix
Version: 1.6.0i1
Restarting the CMC while a downtime is active for a vanished host/service
could lead to a crash. This has been fixed.
ID: 5824
Title: Agent Bakery: Fixed missing baked packages
Component: WATO
Level: 1
Class: Bug fix
Version: 1.6.0i1
During the agent bake process some previously generated symlinks went missing.
The baking itself went fine, but the symlinks pointing to the bake result were no longer available.
As a result, the agent bakery GUI showed some packages as "Not available".
This is a preliminary fix, until we find the root cause of this problem.
There is also a console workaround for this problem.
Agent baking will always succeed with the command <tt>cmk -v --bake-agents</tt>
Keep in mind, that you need to sign the agents afterwards.
ID: 5498
Title: Allow multiple folders in Agent Bakery Host selection
Component: agents
Level: 1
Class: New feature
Version: 1.6.0i1
Previously, only one WATO-folder could be selected as a filter to enable agent deployment for specific hosts.
This selection has now been extended to an arbitrary number of WATO-folders.
ID: 5823
Title: New Feature: SLA reporting
Component: Multisite
Level: 3
Class: New feature
Version: 1.6.0i1
SLA reports are a continuation of the already existing availability reports.
The data from the availability feature can be additionally modified, before it is evaluated by the SLA requirements.
Currently these two SLA requirements are implemented
<ul>
<li>State Percentage: The service state OK/WARN/CRIT/UNKNOWN is lower/higher than x percent</li>
<li>Outage count: Maximum number of outages with a length of x minutes</li>
</ul>
Note: An upcoming SLA requirement will be "Minimum time between outages"
Before the availability data gets forwarded to the computation plugins (which check the actual requirements) it is
<li>further shortened by applying timeperiods, for example "Only check weekdays"</li>
<li>cut into mulitple timeframes (daily/weekly/monthly), specified by period in the SLA definition</li>
</ul>
Each timeframe is computed separately, so you will get several SLA results, if the timerange you are interested in spans multiple SLA periods.
Configuration
First of all you need to configure a SLA definition. Just like views and reports, SLA definitions are configured per user,
so you can setup a SLA and publish it to other users.
SLA definitions are not inherently bound to services.
A SLA definition can be assigned to a service, via the WATO rule <tt>Assign SLA to service</tt>.
For views, the multisite GUI currently offers two different painters to display SLA information
<ul>
<li>SLA - Service specific: This painter renders SLA definitions, which were assigned by WATO rule. Therefore, one table
column in a view can display multiple SLA definition types. The timerange, however, is fixed for all SLAs and can be configured in the painter</li>
<li>SLA - Column specific: This painter renders the same SLA definition for all services in the table</li>
</ul>
There are several configuration options for both painters.
<ul>
<li>SLA timerange: The timerange specifies the start and end date you are interested in. A SLA definition only has a
recurring period (e.g. weekly). So if you have a SLA definition with a monthly period and set the timerange from
01.01.2018 to 31.03.2018, you will get three separate SLA results, one for each month</li>
<li>Layout options: With these options you can configure the content of the painter. You may also choose only to display
the SLA name, which means no actual SLA computation, hereby saving performance</li>
<li>Plugin display options</li>Allows you to configure the precision of percentage (float) values and additional layout options</li>
</ul>
There is also a SLA details page available. This page offers detailed information regarding the computation.
<ul>
<li>Availability rawdata used in computation</li>
<li>Aggregated results (the actual SLA outcome) over all computation plugins</li>
<li>Subresults for each used computation plugin</li>
<li>SLA specification: Includes all settings which were used to create this report</li>
</ul>
Please note that this feature is quite new and still under heavy development.
The goal in version 1.5 is to get some hands on experience and add some minor improvements and bugfixes over time.
Exporting the SLA data into PDF reports is currently only supported within views.
Later on, the SLA details page will also receive a "Export to PDF" button.
ID: 5822
Title: WATO Web-API set_ruleset: Now able to delete complete rulesets from folders
Component: WATO
Level: 1
Class: Bug fix
Version: 1.6.0i1
Removing all rulesets of a specific type from a folder always failed with the exception
<tt>'list' object has no attribute 'get'</tt>. This has been fixed.
ID: 5821
Title: Fixed exception during configuration changes
Component: WATO
Level: 1
Class: Bug fix
Version: 1.6.0i1
This exception could happens on various instances. For example
when saving global settings or during the activate changes phase.
The exception text showed <tt>super(type, obj): obj must be an instance or subtype of type</tt>.