Restore_attribute() from API

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.

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.


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.

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