API Call to revert modified attributes vs. editing modified-attributes.conf

[abaumgaertner]

Is your feature request related to a problem? Please describe.

It is not possible (to my current knowledge) to reset attributes like custom varibles, notification flag etc. after modification via Icinga2 API (or Icingaweb2 for "Feature Commands")

After modifying the value of an attribute, it is persisted in modified-attributes.conf and will override values provided in configuration files.
e.g.

var obj = get_object("Host", "test")
if (obj) {
        obj.modify_attribute("enable_notifications", true)
        obj.version = 1581513322.828091
}

While this is greatly desired for some scenarios (disable notifications will survive an icinga2 service restart / director deployment), it causes problems in others: it is not possibe to give the value from configuration precedence again (unless you stop icinga2 and remove the corresponding entry from modified-attributes.conf).

Please provide a possibilty to revert modified attributes to default (configuration) value.

Describe the solution you'd like

API Call (maybe specific endpoint) to clear / revert modified attributes.
It would be great to implement this in icingaweb2 for host/service "Feature Commands" - revert to config.

Describe alternatives you've considered

stop Icinga2, manually remove entry from modified-attributes.conf, start icinga2

[julianbrost]

#8036 could probably also fix this. Or do you want a call to explicitly reset all attributes of a single object?

[abaumgaertner]

It would be great to query for modified attributes.
Maybe an additional structure that lists the modified attributes and idealy the inital config value.

@julianbrost Thanks for the reference. There might be some inconsitencies with #8036

1. Complex custom vars (.e.g json strings or "_override_servicevars" ) would need exact matching to be "forgotten" / reset. And there is no way to know that the reset worked.
2. Proposes an implicit functionality. the provided example would suggest that a config change of the intial value from Linux to Ubuntu triggers all custom vars that were explicitly set to Ubuntu via API would be reset due to now matching value of custom var and config. After a template change back from Linux to Ubuntu, this would cause the explicitly set Ubuntu Variables now automatically changed back to Linux. There will be headscratching down this road ...

A call to explicitly reset attributes seems a controlled way.
curl -k -v -u root:icinga -H 'Accept: application/json' -X POST 'https://localhost:5665/v1/objects/hosts/resetattributes/example.localdomain' -d '{"attrs": {"vars.os": null, "enable_notifications": null, , "vars.dummyarray": [], "_override_servicevars": null}, "pretty": true}'

curl -k -v -u root:icinga -H 'Accept: application/json' -X POST 'https://localhost:5665/v1/objects/services/resetattributes/example.localdomain' -d '{"attrs": {"vars.os": null, "enable_notifications": null, , "vars.dummy array": [], "_override_servicevars": null}, "pretty": true}'

curl -k -v -u root:icinga -H 'Accept: application/json' -X POST 'https://localhost:5665/v1/objects/hosts/resetattributes -d '{ "filter": "match(\"OpenStack\",host.groups, MatchAny)", "pretty": true, "attrs": { "enable_notifications": null, "vars.dummy array": [] } }'

All attributes passed would be reset to default values, irrespective of the passed value. Maybe not the most consistent ( you have to specify a value for a json variable ) approach but would work nice with filter and current implementation.

or

curl -k -v -u root:icinga -H 'Accept: application/json' -X POST 'https://localhost:5665/v1/objects/hosts/resetattributes/example.localdomain/enable_notifications'
curl -k -v -u root:icinga -H 'Accept: application/json' -X POST 'https://localhost:5665/v1/objects/hosts/resetattributes/example.localdomain/vars.os'
curl -k -v -u root:icinga -H 'Accept: application/json' -X POST 'https://localhost:5665/v1/objects/hosts/resetattributes/example.localdomain/vars.dummy%20array'