How to delete service templates and applies with fileshipper that created them?

I am familiarizing myself with Director (version 1.6.2 under Icinga r2.13.2-1) and have been able to import hosts (objects) and services (both templates and applies) with fileshipper input sources. I am using three source JSON files for the three kinds and three corresponding input sources and sync rules each. With that, I can import 2 objects of each kind, as expected. The apply rules are currently trivial, they assign each service to a host with a filter that refers to the host name.

As a second step, I’d now like to delete the imported objects again by emptying the source JSON files (placing empty JSON arrays in them), reimporting, and resyncing. This does work for the hosts, but the services (both tempates and applies) apparently stay. I suspect this is “somehow” by design and related to what is mentioned here: “An apply rule would be the same object but object_type set to apply, be careful with service apply rules as they are not unique objects.”

So is it possible to delete all of these objects with the same import source (fileshipper) that created them and as I have tried, or is there a fundamental hurdle because of the different nature of templates and applies opposite single objects? The linked question does mention a workaround that employs service sets, but I’d like to first better understand the nature of the problem (if any) first.

Update: I have meanwhile noticed that the service templates and apply rules stay because their sync rules apparently do not recognize any changes, hence no resync occurs. Also icingacli director syncrule check --id ... reports them as in-sync (unexpected by me at this point) while icingacli director importsource fetch -id ... reports [] (as expected).

Looks to me by now as if this may be related to open issues #2015 “ERROR: the import of service apply rules creates identical rules = deployment error” (from 2019) and #934 “Use different DB tables for different object_types” (from 2017).

I’ve pretty much concluded (also given the lack of response here and the number of its open GitHub tickets) that the Director is currently not a good choice when apply rules should be part of the game. Disabling it has turned out to be a good step forward (in my situation) so far.

1 Like