Please help me clear Pending Deployments on my Activity log

Icinga Web 2
1

Hi all,
I’ve been trying to learn Icinga2 for a while now as I inherited this configuration from a previous member of employment and I find it really amazing. However I tried to make a few changes. i.e. I tried to remove the QNAP CPU checks as our QNAPS are constantly busy and i constantly get warnings. Unfortunately I think I did something wrong, as when I try to deploy I get the following error:
Undefined offset: 1 (TemplateTree.php:186)
So I figured ok, maybe lets just click on Restore former object hoping that it would fix whatever mistake I made. However when I click that, it then comes up with the following error:

    • Storing icinga_service_set[{“host_id”:“33”,“object_name”:“QNAP Checks”}] failed: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry ‘QNAP Checks-33’ for key ‘object_key’, query was: UPDATE icinga_service_set SET object_type = ?, description = ?, host_id = ? WHERE (id = 6) {array ( ‘id’ => ‘6’, ‘host_id’ => ‘33’, ‘object_name’ => ‘QNAP Checks’, ‘object_type’ => ‘object’, ‘description’ => NULL, ‘assign_filter’ => NULL, )} (DbObject.php:814)

I don’t understand what’s going on. IcingaWeb2 is still working well, the QNAP CPU checks are still happening, it’s just the activity log has these pending deployments and I have no idea what to do to get rid of them, and I don’t think I can make any other deployments until this is resolved.

Please can somebody advise me on how I can fix this.
I’ve made deployments before without any of these errors occurring, I just don’t know where or how I went wrong and how to rectify this.

2

Hey! First off, for readability, we prefer that posts are formatted according to these guidelines:

With a pending deployment, it sounds like you are doing this in Icinga Director, is that right?

From the activity log, you should just be able to click “Deploy X pending changes” as shown in the below screenshot:

image
image1138×138 11.4 KB

This screen is accessed from the Menu options:
Icinga Director > Activity Log

Under Icinga Director > Automation > Jobs you can configure a config deploy as well. It will automatically kick off deployments at a set interval (if there are changes).

Our environment has 10s-100s of automated host/service changes daily. If you have any “Import Sources” or “Sync Rules” you can also configure these to happen auto-magically as well.

3

Hi Ben, apologies for not following the correct formatting.
And yes I did click on the Deploy xx pending changes. That is when I receive the message in my initial post… “Undefined offset: 1 (TemplateTree.php:186)”
I don’t understand why that came up, normally I make changes and and then go to the Activity Log and click on Deploy and it all goes well, this time I removed the QNAP Service Template (by mistake) instead of disabling the QNAP CPU Check command. And now this is where I am, stuck with deployments that will not go through. And I cannot revert/restore object due to the error that comes up as stipulated in my original post.

4

Sounds like something may have borked (or another dependency for the service is missing).

You can use the director to revert back to a previous deployment as well:

Icinga Director > Deployments > Select the deployment that you want to go back to from the list > Config > “Redeploy now”

Example:

image
image1702×319 34.4 KB

If that doesn’t work, I’m out of ideas :frowning:

Edit to add:
Your “Last known good deployment” would ideally be the one before you started making any changes.

5

That didn’t work. It deploys, however the pending deployments are still there in queue unable to be removed.

Thanks for trying.

1 Like
6

thanks for the awesome information.

1 Like
7

Was it possible to solve the problem? I have a similar problem

8

I ended up scrapping the whole system for “checkmk” instead. Much simpler to use and configure. And in my little experience, it seems like their community is much more active and helpful.

9

thx Sean; Unfortunately this is not an option. I need a solution urgently. Wo can help here

10

Have you checked if your icinga-director service is running?
(Installation - Icinga Director)

11

yes service is running:
icinga2.service - Icinga host/service/network monitoring system
Loaded: loaded (/usr/lib/systemd/system/icinga2.service; enabled; vendor preset: disabled)
Active: active (running) since Mo 2022-01-10 11:18:44 CET; 4 months 12 days ago

12

Then please describe your problem in detail, what the current problem is and what you are trying to do. Best with screenshots and information about used versions.

I suggest opening a new thread if your problem doesn’t match the title of this one (and this one is pretty old)

14

This is not the Icinga Director deamon!

Please check again this installation instructions.

15

I had a similar problem… I solved it in a messy way with a sledge hammer - it worked, but you should consider your specific use case before just applying this fix.

Scenario: My icinga director wizard must have missed the external imports somewhere on my initial load, so I was messing around and setup the data import and sync features. Please note, this is not a production server, just playing around after a few years away from the software. Things were working well, hostgroups, hosts everything was showing up. When I got to the commands things went sideways. The deployments started stacking up, 200+ at a time. Everytime I tried to resolve it another 200 pending deployments. I could not find a way to cleanly erase them without dropping the table in the database. After a little thought here is what I put together:

#!/bin/bash

output="$(icingacli director config deploy)"
until ! echo ${output} | grep 'ERROR'; do
	output="$(icingacli director config deploy)"
	icingacli director command delete $(echo ${output} | awk -F'>' '{print $2}' | xargs)
done

This essentially tries to deploy, then deletes the command that is thrown in the error. It looped through all of the my duplicate commands and I was able to complete the deployments that were left over.

Do yourself a favor and perform a mysqldump before you try this, and again please remember that I was in a non production 100% sandbox environment. This was just my last step before dropping the dagabase and reimporting the schema from /usr/share/icinga2-ido-mysql/schema/mysql.sql

A few things to note:

  • I installed from master in git (bad idea, I know better, I think was related to the issue)
  • I should have just done an apt-cache search icinga because I would have found plenty of the modules are ready to be installed with the package manager, cleanly, with stable code.
  • After “fixing” the problem I ended up deleting the director module, dropping the database, reinstalling through apt and reinstantiating the database - just to make sure i had a clean baseline for further testing.