Newbie API user - "where'd my object go?" question

Icinga 2
1

Hi… I am just getting started with the API and I seemed to have successfully created an object and I can retrieve it via an API query. However, it doesn’t show up when I list objects from the icinga2 CLI. Could some please explain (or direct me somewhere) how an object created via the API differs from one created by the static config files? My expectation was that objects created by the API would not persist through a restart but I figured in other respects they’d look like the normal config objects.

Any help improving my understanding of this area would be greatly appreciated. Thanks!

Andy

2

there should be no difference between an Object created by API or by config.
Could you give us an example of what you did to create the object and then search for it?

3

Hi,

a runtime created object lives in memory and is persisted on disk storage. The main difference here is that the full configuration is not re-read again, only the created object in its scope.

If you edit the static configuration files, a config validation is run on startup loading these config items into memory and compiling them as config objects. In addition to that, such a startup also dumps additional debug information which is known as icinga2.debug cache file.

This cache file is used for icinga2 object list to show the origins of specific attributes and overrides with templates and so on.

This information is not available for runtime created objects, and as such, this cache file is never updated for any type of object creation via API. Also, this is for performance matters, as 1000 requests would trigger 1000 times updating the debug file which can be several megabytes of netstring encoded JSON data. One could argue to do that in a certain interval, but we haven’t thought about this and performance implications just yet.

TL;DR - a runtime created object is not immediately visible via icinga2 object list. The latter needs a full config validation with icinga2 daemon -C or restart/reload to have everything in that cache file.

Cheers,
Michael

4

Hi, thanks for your reply! I made a rest client with some simple, abstracted methods so the guts will be hidden here but I think you’ll get the gist:

def templates = ["generic-oracle-cmd"]
def command = "/usr/lib64/nagios/plugins/local/mde_validator/mde_validator.sh"
def attrs = ["command":[command],"vars.validator":"OracleScriptEvaluator"]
// this create part works, the response is:
// 09:11:26.577 [main] DEBUG org.myhost.build.rest.RestHttpClient - Response from request to create sanity_check_rights_library_sql:{"results":[{"code":200,"status":"Object was created"}]}
client.createObject("checkcommands",one_off,templates,attrs)

// this part works, the response is:
// 09:27:28.068 [main] TRACE org.myhost.build.rest.RestHttpClient - Pulling response that we hope is a JSON object: '{"results":[{"attrs":{"__name":"sanity_check_rights_library_sql","active":true,"arguments":{"-C":"$connstr$","-c":"$validator$","-p":"$password$","-u":"$username$","-vvv":""},"command":["/usr/lib64/nagios/plugins/local/mde_validator/mde_validator.sh"],"env":{"TNS_ADMIN":"/etc/icinga2/plugin-configs"},"execute":{"arguments":["checkable","cr","resolvedMacros","useResolvedMacros"],"deprecated":false,"name":"Internal#PluginCheck","side_effect_free":false,"type":"Function"},"ha_mode":0.0,"name":"sanity_check_rights_library_sql","original_attributes":null,"package":"_api","paused":false,"source_location":{"first_column":0.0,"first_line":1.0,"last_column":52.0,"last_line":1.0,"path":"/var/lib/icinga2/api/packages/_api/950d5775-d32f-49dd-ad04-f6d11497b898/conf.d/checkcommands/sanity_check_rights_library_sql.conf"},"templates":["sanity_check_rights_library_sql","plugin-check-command","generic-oracle-cmd"],"timeout":60.0,"type":"CheckCommand","vars":{"connstr":"$service.vars.svc_connstr$","dbname":"$service.vars.svc_dbname$","password":"$service.vars.svc_passwd$","username":"$service.vars.svc_uname$","validator":"OracleScriptEvaluator"},"version":1558455086.478566885,"zone":"cscloudxn2133.cloud.myhost.org"},"joins":{},"meta":{},"name":"sanity_check_rights_library_sql","type":"CheckCommand"}]}'
println client.getObject("checkcommands","sanity_check_rights_library_sql")

// this part returns nothing:
// -bash-4.1$ icinga2 object list --type Service |grep sanity
// -bash-4.1$

I’ve reloaded/validated numerous times since I’ve put this task on the shelf and have been doing other things.

Thoughts?

Andy

5

Thanks, for your reply, Michael, that really helps understand the distinction between the static files and those created during runtime. It’s a plus to know it persists, I was thinking I’d have to setup a post-script that reloads all my dynamic scripts, that’s awesome.

So, alas, I’m not sure why I’m not seeing the checkcommand. I guess next step I could try to create a service against the command and see if it fails. Or can you see something else that would explain why I’m not able to see it in the object list command?

Andy