Restore_attribute() from API

Icinga 2
, ,
1

Hello,
I would like to know if i can call restore_attribute() function directly from API to reset an object variables, i couldn’t find it in the documentation, I’m not sure if it’s possible with the release I’m currently using: r2.10.5-1.

I found out i could use it from console in this way :

get_object(“Service”, “host1!check_custom”).restore_attribute(“vars”)

Here are the reasons why i’m looking forward to use it in this way :
I’m trying to use both the package/stage system and the API runtime objects to manage services tresholds pushed on the fly to adapt production needs, and keep the advantages the package system provides.

After some testing, i found out that /var/lib/icinga2/modified-attributes.conf saves all modifications made at runtime, and it does not purge objects after a new package version whether the objects vars were updated or not, however it works fine when the modification comes from runtime.
I also validated this by checking vars and original_attributes in console.
So, when i’m creating a new package, changing the variables at runtime with api and pushing a newer version of the package with updated vars, they are overridden by the thoses previously defined at runtime.

This is why i want to be able to use restore_attribute from the API in order to purge runtime modifications before pushing a new stage.

2

When using config packages, I’d advise against mixing this with runtime object creation and modification. Both ways influence each other. That being said, if a config package needs an update, push a new update as new stage inside. The way original_attributes and POST updates against runtime object work, are different.

restore_attribute() is more of an internal DSL function than to be exposed via API. Since original_attributes already is there for those runtime object, that’s the preferred way of resetting this.

Cheers,
Michael

3

Thank you for your fast answer !

Well then, it might be interesting in a future update of the documentation to explain how they influence each other, so that it makes clear for what use case we can mix and when we should not.

4

You‘re welcome to send in a PR updating the docs :kissing_heart: