[icinga-checkins] icinga.org: icinga2-migration/master: update readme for dependencies and escalations

git at icinga.org git at icinga.org
Sun Jun 15 01:56:17 CEST 2014


Module: icinga2-migration
Branch: master
Commit: 6b0e56c705852cf8d25c188353a368531df03094
URL:    https://git.icinga.org/?p=icinga2-migration.git;a=commit;h=6b0e56c705852cf8d25c188353a368531df03094

Author: Michael Friedrich <michael.friedrich at netways.de>
Date:   Sun Jun 15 01:46:01 2014 +0200

update readme for dependencies and escalations

---

 README.md |   53 ++++++++++++++++++++++++++++++++---------------------
 1 file changed, 32 insertions(+), 21 deletions(-)

diff --git a/README.md b/README.md
index d9d0b0d..3ed9a5f 100644
--- a/README.md
+++ b/README.md
@@ -9,7 +9,7 @@ object configuration into native Icinga 2 configuration objects.
 > and understand the new dynamic configuration syntax.
 >
 > Check the manual migration hints and also manually migrate the
-> configuration.
+> configuration at https://docs.icinga.org/icinga2/latest/
 
 ## General Information
 
@@ -24,7 +24,7 @@ module for configuration migration from Icinga 1.x to 2.x.
 
 ## Requirements
 
-* Apache2 with PHP >= 5.3.0 enabled
+* PHP CLI >= 5.3.x
 * PHP Zend Framework
 
 Debian requires the `zendframework` package installed.
@@ -45,19 +45,14 @@ config is located in `bin/run`.
 
 ## Manual Migration Required
 
-Currently the following Icinga 1.x objects must be migrated manually:
-
-* Escalations
-* Dependencies
-
-These objects are either not directly compatible, or would lead into
-(logic) errors without knowing about your configuration strategy.
-
-Furthermore, these Icinga 1.x specifics are not supported either:
+These Icinga 1.x specifics are not supported:
 
 * Regular expressions and wildcard matching
-* Invalid objects ('name' instead of 'service_description' for service objects)
+* Invalid objects ('name' instead of 'service\_description' for service objects)
 * Invalid templates (missing 'name' attribute)
+* More unknown (not documented) object tricks
+* Special macros
+* Deprecated attributes and objects ({host,service}extinfo, etc)
 
 
 ## Automatic Migration
@@ -68,18 +63,19 @@ this migration script:
 * All compatible object attributes
 * Keep the template tree (`register 0` -> `template`) and import these templates (`use` -> `import`)
 * Keep service relation ship to `host_name` and `hostgroup_name`
-* Use the apply rules wherever possible (e.g. for service with `hostgroup_name` attribute)
+* Use the apply rules wherever possible (e.g. for service with `hostgroup_name` attribute, Dependencies, Escalation Notifications, etc)
 * Assign group members directly
 * Migrate host/service contacts for notifications into the new Notification logic
 * Convert the notification options to state/type filters
 * Create additional `EventCommand` objects for event handler migration
 * Create additional `NotificationCommand` objects for notification migration
 * Migrate the ARGn command arguments into custom attributes for commands
+* Convert custom variables into custom attributes
 * Replace runtime macros in command line for check, event, notification commands
-* Replace runtime macros in notes, notes_url, action_url, icon_image attributes
+* Replace runtime macros in notes, notes\_url, action\_url, icon\_image attributes
 * Migrate host parents into simple host dependencies
 * Treat all intervals as minute duration literal - append `m`
-* Exclusions in service->hostgroup and group membership assignments
+* Exclusions in service => hostgroup mappings and group membership assignments
 * Turn * (all) into a match function in expressions
 * All comma separated lists are converted into arrays, if possible (except contacts for notifications)
 
@@ -95,6 +91,17 @@ this migration script:
   timeperiod    | TimePeriod						| only basic
   command       | CheckCommand, NotificationCommand, EventCommand	| cleanup required
 
+### Templates
+
+  Template / Command		| Purpose
+  ------------------------------|------------------------------
+  generic-host-notification	| generated notifications
+  generic-mail-notification	| generated notifications
+  generic-escalation-dummy	| escalations w/o command
+  migration-check-command	| generic check command with `vars.USER1 = PluginDir` mapping
+  migration-event-command	| generic event command with `vars.USER1 = PluginDir` mapping
+  migration-notification-command | generic notification command with `vars.USER1 = PluginDir` mapping
+
 
 ## Known Caveats
 
@@ -103,11 +110,18 @@ this migration script:
 The contact-to-notification migration generates a new notification object
 per unique host/service contact (also in groups) and its
 {host,service}_notification_command.
+The `first_notification_delay` attribute is not automatically converted.
 
 * Better: Get an idea how the new Icinga 2 notifications work, and
 apply them based on your group memberships, custom attributes, or host
 relations!
 
+### Escalations
+
+The `generic-escalation-dummy` command acts as placeholder for a proper
+notification command. There is no way to automagically get the right
+notification command from the assigned contacts and contactgroups.
+
 ## Commands
 
 Event and Notification commands will be added once used. The Icinga 1.x
@@ -119,12 +133,9 @@ The parent `hostgroup_name` is not supported. Migrate this dependency
 manually. The `host_name` attribute cannot contrain multiple entries, only
 the first one will be processed. `inherits_parent` is ignored, default
 is enabled.
-
-## Escalations
-
-The `generic-escalation-dummy` command acts as placeholder for a proper
-notification command. There is no way to automagically get the right
-notification command from the assigned contacts and contactgroups.
+By default all dependencies will disable notifications and checks.
+`notification_failure_criteria` and `execution_failure_criteria` are not
+1:1 the same for the migration process.
 
 ## Timeperiods
 



More information about the icinga-checkins mailing list