Skip to content

Commit

Permalink
Migration: Remove broken script, update documentation for work-in-pro…
Browse files Browse the repository at this point in the history
…gress.

Refs #5821
  • Loading branch information
Michael Friedrich authored and Michael Friedrich committed May 4, 2014
1 parent 6d93679 commit f85fae8
Show file tree
Hide file tree
Showing 5 changed files with 12 additions and 4,769 deletions.
1 change: 0 additions & 1 deletion debian/icinga2-common.install
Expand Up @@ -2,7 +2,6 @@ debian/tmp/etc/icinga2
debian/config/apt.conf etc/icinga2/conf.d/hosts/localhost
usr/bin/icinga2-build*
usr/bin/icinga2-sign-key
usr/bin/icinga2-migrate-config
usr/sbin/icinga2-*-feature
usr/sbin/icinga2-setup-agent
usr/sbin/icinga2-discover-agent
Expand Down
10 changes: 3 additions & 7 deletions doc/7-migration.md
Expand Up @@ -8,24 +8,20 @@ Icinga 2 ships its own config migration script.

### <a id="configuration-migration-script"></a> Configuration Migration Script

TODO
In order to migrate existing configuration in Icinga 1.x format
the Icinga CLI as part of the Icinga Web 2 project will provide
a conversion module.

Due to the complexity of the Icinga 1.x configuration format the migration
script might not currently work for all use cases.

The config migration script provides support for basic Icinga 1.x
configuration format migration to native Icinga 2 configuration syntax.

The migration script tries to preserve your existing template structure and
adds new templates where appropriate. However, the original file structure is
not preserved.

The migration script uses templates from the Icinga Template Library where
possible.

# mkdir /etc/icinga2/conf.d/migrate
# /usr/bin/icinga2-migrate-config -c /etc/icinga/icinga.cfg -o /etc/icinga2/conf.d/migrate

### <a id="manual-config-migration"></a> Manual Config Migration

For a long-term migration of your configuration you should consider re-creating
Expand Down
8 changes: 1 addition & 7 deletions tools/CMakeLists.txt
Expand Up @@ -32,12 +32,6 @@ if(UNIX OR CYGWIN)
)

install(CODE "execute_process(COMMAND \"${CMAKE_COMMAND}\" -E create_symlink ./icinga2-enable-feature \"\$ENV{DESTDIR}${CMAKE_INSTALL_FULL_SBINDIR}/icinga2-disable-feature\")")

install(
FILES ${CMAKE_CURRENT_SOURCE_DIR}/migration/icinga2-migrate-config
DESTINATION ${CMAKE_INSTALL_BINDIR}
PERMISSIONS OWNER_READ OWNER_WRITE OWNER_EXECUTE GROUP_READ GROUP_EXECUTE WORLD_READ WORLD_EXECUTE
)
endif()

if(MSVC)
Expand All @@ -51,4 +45,4 @@ if(MSVC)
FILES ${CMAKE_CURRENT_SOURCE_DIR}/icinga2-setup-agent/bin/\${CMAKE_INSTALL_CONFIG_NAME}/Icinga2SetupAgent.exe
DESTINATION ${CMAKE_INSTALL_SBINDIR}
)
endif()
endif()
103 changes: 8 additions & 95 deletions tools/migration/README
@@ -1,99 +1,12 @@
ICINGA 2 CONVERSION SCRIPT FOR ICINGA 1.x CONFIGURATION
=======================================================
Icinga 2 Migration Script
=========================

This config conversion script provides support for basic Icinga 1.x
configuration format conversion to native Icinga 2.x configuration syntax.
In order to migrate existing configuration in Icinga 1.x format
the Icinga CLI as part of the Icinga Web 2 project will provide
a conversion module.

It won't just compile all objects and drop them at once, but keep your
existing 1.x template structure, only adding a new host->service link relation.
For work-in-progress details please check

The script will also detect the "attach service to hostgroup and put
hosts as members" trick from 1.x and convert that into Icinga2's template
system.
https://dev.icinga.org/issues/5821
https://dev.icinga.org/issues/5929

Furthermore the old "service with contacts and notification commands" logic
will be converted into Icinga2's logic with new notification objects,
allowing to define notifications directly on the service definition then.

Commands will be split by type (Check, Event, Notification) and relinked where
possible. The host's check_command is dropped, and a possible host check service
looked up, if possible. Otherwise a new service object will be added and linked.

Notifications will be built based on the service->contact relations, and
escalations will also be merged into notifications, having times begin/end as
additional attributes. Notification options will be converted into the new Icinga2
logic.

Dependencies and Parents are resolved into host and service dependencies with
many objects tricks as well.

Timeperiods will be converted as is, because Icinga2's ITL provides the legacy-timeperiod
template which supports that format for compatibility reasons.

Custom attributes like custom variables, *_urls, etc will be collected into the
custom dictionary, while possible macros are automagically converted into the macro
dictionary (freely definable macros in Icinga 2.x).

All required templates will be inherited from Icinga2's Template Library (ITL).

Regular expressions are not supported, also for the reason that this is optional in Icinga 1.x

RUN
# mkdir /etc/icinga2/migration
# /usr/bin/icinga2-migrate-config -c /etc/icinga/icinga.cfg -o /etc/icinga2/migration/

HELP
# /usr/bin/icinga2-migrate-config -h

VERBOSE
# mkdir /etc/icinga2/migration
# /usr/bin/icinga2-migrate-config -v -c /etc/icinga/icinga.cfg -o /etc/icinga2/migration/

TEST
Include /etc/icinga2/migration in /etc/icinga2/icinga2.conf and restart Icinga 2

# vim /etc/icinga2/icinga2.conf

include "migration/*.conf"

# service icinga2 restart


REQUIREMENTS
- Perl:
Data::Dumper
File::Find
Storable qw(dclone)
Getopt::Long qw(:config no_ignore_case bundling)
Pod::Usage

- Icinga2 ITL


DEBUG
Compile Icinga2 with --enable-debug=yes and start it with -x. Alternatively, define the
ConsoleLogger Object and set severity to "debug".

object ConsoleLogger "my-debug-log" {
severity = "debug"
}


NOTES
- Excludes (will be ignored in member lists)
- Wildcards (* means all)
- additive + to += logic (only for the current object, does not work with users)
- Dependencies (host deps and parents are merged)
- Commands will be split into Check|Event|Notification Commands
- null (disable inheritance) only works non-converted values (not on contacts, commands, etc) being 0
- notification_options string w,u,f is converted to
notification_{state,type}_filter = (StateFilterWarning | StateFilterUnknown | NotificationFilterFlapping)
- service escalations are converted into notifications with times = begin/end
begin = first_notification * notification_interval (now a time, not a counter)
- custom variables, *_url, *image*, notes, 2d_coords will be collected and stashed into the "custom" dictionary
similar to the macros dictionary. note: attributes starting with a number must be quoted.

TODO
- Dependency attributes: failure_criteria, inherits_parents, timeperiods
- Flapping Thresholds: old vs new logic
- some special object tricks, regex

0 comments on commit f85fae8

Please sign in to comment.