Maintenance.Update method seems to be broken since upgrading to 6.0

[ericallenpaul]

We had some automated maintenance scripts to put things in maintenance during updates or code rolls and after upgrading to 6.0 they stopped working.
The weird thing is that the update call won't accept any "timeperiods" with out complaining that "timeperiods" is an invalid parameter.
So a request like this:

{
    "method":  "maintenance.update",
    "params":  {
                   "active_since":  "1635397200",
                   "maintenanceid":  "252",
                   "name":  "Portal Even",
                   "description":  "",
                   "maintenance_type":  "0",
                   "groupids":  [
                                    322
                                ],
                   "timeperiods":  [
                                       {
                                           "timeperiod_type":  "0",
                                           "every":  "1",
                                           "month":  "0",
                                           "dayofweek":  "0",
                                           "day":  "1",
                                           "start_time":  "0",
                                           "period":  "300",
                                           "start_date":  "1635423480"
                                       }
                   ],
                   "active_till":  "2140491600"
               },
    "id":  1,
    "jsonrpc":  "2.0",
    "auth":  "XXXXXXXXXXXXX"
}

Fails with the error:

{
    "jsonrpc": "2.0",
    "error": {
        "code": -32602,
        "message": "Invalid params.",
        "data": "Invalid parameter \"/1/timeperiods/1\": unexpected parameter \"start_time\"."
    },
    "id": 1
}

If I remove start_time it complains about the next parameter and so on.
If I remove "timeperiods" the request succeeds.

{
"method": "maintenance.update",
"params": {
"active_since": "1635397200",
"maintenanceid": "252",
"name": "Portal Even",
"description": "",
"maintenance_type": "0",
"groupids": [
322
],

"active_till": "2140491600"
},
"id": 1,
"jsonrpc": "2.0",
"auth": "XXXXXXXXXXXXX"
}

The real irony here is that the json data I am sending back is what I got by using "maintenance.get"
So it's complaining about it's own data.

Is something about this call broken in 6.0 or did the call change but the documentation didn't?

Anyone else having issues?

[tim.mooney]

Is it coming from this:

https://www.zabbix.com/documentation/current/en/manual/api/changes_5.4_-_6.0

specifically, this: https://support.zabbix.com/browse/ZBXNEXT-6890

The documentation has been updated; if you switch back and forth between the 5.0 and 6.0 versions of the maintenance.update docs, you can see there are changes.

I don't have 6.0.x yet (I'm waiting for it to stabilize before I think about upgrading), so I can't easily test what's going on.

[ericallenpaul]

Well I do see the differences now. I must have been looking at it wrong earlier. So it looks like Hosts becomes HostIds and Groups became GroupIds and the timeperiod object no longer has timeperiodid.
Those differences are accounted for already in my JSON request though. I guess I need to figure out how to report a bug. I looked at their process but it didn't make sense to me and everything I clicked on seemed to lead me to a page that requires authentication?

Thanks,

Eric

[ericallenpaul]

OK figured out how to post a bug report. Guess well see how this goes.

[ericallenpaul]

Looks like it is confirmed as a bug: https://support.zabbix.com/browse/ZBX-20804
Hope it get's fixed soon.

[stevene1900]

Hello,

I have run into same exact error, after it working fine in older version of Zabbix. I tried with 6.0.7 and 6.0.10. Is there a work around?

Trying to follow along the bug report and I have to assume the issue is now being handled by https://support.zabbix.com/browse/ZBX-21545 ?

If that is right, then this issue may be corrected in next release of Zabbix 6 with 6.0.11. Am I reading that right?

Thanks

[ericallenpaul]

It is being fixed in a current sprint (https://support.zabbix.com/browse/ZBX-21545) that I think ends at the end of this month.

[stevene1900]

I realized what the issue was on my end.

If timeperiod_type is of type 0 (which is "one time only"), then start_time is not needed.

I noticed this for start_time in the Zabbix 6.0 api documentation (notice no mention of "one time only" type of maintenance):

https://www.zabbix.com/documentation...ct#time-period

start_time

integer

Time of day when the maintenance starts in seconds. Used for daily, weekly and monthly periods. The given value will be rounded down to minutes. Default: 0.

Once i removed start_time where timeperiod_type = 0, then the call went through just fine.

This was realized against 6.0.10.

Also for "one time only" maintenance, I only specify this in timeperiods (I dont see need for any other properties, also please forgive use of variables):


"timeperiods": [
{
"timeperiod_type": 0,
"start_date": ${UnixStartDateTime},
"period": ${durationInSeconds}
}



Thanks.