Deployment fails with "API request failed: Conflicting request, there is already an ongoing package update in process. Please try again later. (RestApiResponse.php:113)"

[mwaldmueller]

Current Behavior

Deployment fails with "API request failed: Conflicting request, there is already an ongoing package update in process. Please try again later. (RestApiResponse.php:113)"

Your Environment

• Director version (System - About): 1.10.2
• Icinga Web 2 version and modules (System - About): 2.11.3
• Icinga 2 version (icinga2 --version): 2.13.6
• Operating System and version: RHEL 8
• Webserver, PHP versions: Apache, PHP 8.0

[Thomas-Gelf]

Hi @mwaldmueller,

there isn't much the Director can do about this. Deployments to Icinga have initially been implemented in a way that allows parallel deployments. That's why those dynamic stage names exist. As far as I can recall, this has recently been changed: Icinga now refuses Deployments, while a former one is still going on.

Old behavior used to be: interrupt the ongoing validation / new process, and launch a new one for the next deployment.

Cheers, Thomas

[fatslimjoe]

Hi, we have same issue here! Didn't find any solution and didnt jet reload icinga2 service. Will reload interupt this ongoing deployment? We have already tried to redeploy to previous working deployment and didnt happend much.

Thank you.

[fatslimjoe]

Hi,

just to confirm for my previous comment, it was OK. So, redeploy to previous working version then systemctl reload icinga2 ... if there is no more errors in configuration it should be fine and you can deploy again your changes.

Cheers and have fun :)

[DocMAX]

I have a script running that sends deployments. Can i check if an deployment is ongoing via API so that my script waits until it sends? Or is there a better solution to avoid those messages? Putting them into a queue or something...

[carraroj]

ref/NC/806887

[afeefghannam89]

@Thomas-Gelf this is a core problem. I can reproduce this issue. When Icinga2 core can't write out his performance data using his writer features, in my situation InfluxDB, the reload will take some minutes to be finished. As I observed in the Icinga logs, Icinga checks the functionality of his feature at the beginning of the reload, or he tries to export all stacking checks performance date.

When InfluxDB is not running, like in my testing situation, or Icinga can't connect to it, the reload will take longer time as usual. When I disable the influxdb2 feature, the reload will finish very fast and the Director will not through the error referenced in this issue.

[Donien]

ref/NC/814774

[raviks789]

ref/IP/53766