search

Icinga / icingaweb2-module-director

The Director aims to be your new favourite Icinga config deployment tool. Director is designed for those who want to automate their configuration deployment and those who want to grant their “point & click” users easy access to the configuration.
https://icinga.com/docs/director/latest
GNU General Public License v2.0
413 stars 203 forks source link

CLI command /API request for deploymentstatus does not return failed deployments #2830

Open log1-c opened 1 year ago

log1-c commented 1 year ago

Expected Behavior

Running icingacli director config deploymentstatus returns that there currently is a failed deplyoment and exits with EXIT_CODE!=0

Current Behavior

If you have a failed deployment (that possibly prevents reloading icinga or activating new config from a kickstart) the currently is no possibilty to check for said failed deployment (at least to my knowledge).

# icingacli director config deploymentstatus
# icingacli director config deploymentstatus
{
    "active_configuration": {
        "stage_name": "f41e4c2d-4fac-49a7-a80a-bdec4d693ecf",
        "config": "205ac9eb0368266572e467602d348ef597c1b801",
        "activity": "eca91ab4defd589c990c8fb87feaaf06521addce"
    }
}

image

Possible Solution

Make the check return above expected behavior or e.g. add a parameter --failed to check for failed deployments since the last active deployment. Another possible solution could be monitoring automatic jobs for config deployment (if you have any). But this is not a viable way at the moment because you can't monitor/check only one jobs (see https://github.com/Icinga/icingaweb2-module-director/pull/2698 and https://github.com/Icinga/icingaweb2-module-director/issues/2740)

Your Environment

lippserd commented 3 weeks ago

@log1-c thanks for the issue. Expected behavior sounds reasonable to me.

lippserd commented 1 week ago

Doesn't icingacli director health --check deployment do exactly what you need?

log1-c commented 1 week ago

Huh, it does :D don't know why I missed that until now...

Though I personally would favor a "real" timestamp instead of "x minutes ago" in the output as well as displaying the configs checksum like in the deployment log.