mass-migration of api-objects

[K0nne]

Describe the bug

I need to migrate a few thousend hosts and services. These objects were created with api-calls. Our zones have changed and I am in need to move those objects into a new zone.

When I change the zone-attribute of a host and its services in /var/lib/icinga2/api/packages/_api/<individual_name>/conf.d/services and /hosts on the configmaster, the checks for those objects are executed manualy without problems afterwards, but the automatic scheduling seems broken, because the checks are pending now. Manual scheduling works to fix this temporary, but in the next cycle there's no automatic scheduling again.

after zone-attribute modification:

after manual execution:

next automatic cycle:

When I move the zone-attribute back to its original value, scheduling of those checks is working again.

Question

Is there a convenient way to mass-migrate api-objects into another zone? Just the zone-attribute needs to change.
I have no automatic way to perform this.

Your Environment

Include as many relevant details about the environment you experienced the problem in

• Version used (icinga2 --version): 2.13.10
• Operating System and version: RHEL8
• Enabled features (icinga2 feature list):

Disabled features: command compatlog debuglog elasticsearch gelf graphite influxdb2 livestatus opentsdb perfdata statusdata syslog
Enabled features: api checker icingadb influxdb mainlog notification

• Icinga Web 2 version and modules (System - About): 2.12.1

[Al2Klimov]

Hello @K0nne and thank you for reporting!

change the zone-attribute of a host and its services in /var/lib/icinga2/api/packages/_api/<individual_name>/conf.d/services and /hosts on the configmaster

On Fedora 40, I've done exactly this to my Icinga 2.14.3 and reloaded all nodes. The hosts still got checked. Didn't test services so far, but you could try incrementing the version attribute by 1.

Cheers && A/K

[K0nne]

I have tested your suggestion (changed the zones-attribute of a host and its services to the new zone, increased the version-attibute of those objects by 1, reloaded the configmaster and all affected satellites), but unfortunately it did not change anything.