6.0.0 Template import fails on dependencies that look OK

[Linwood]

I have a bunch of templates that all depend on a ping check trigger. I upgraded from 4.5.4 to 6.0.0, and it did whatever magic it needed, the templates are all there, the hosts' implementation of them all seem to work.

I am trying to standardize installs between clients, and so I am exporting a template from system A, and importing into system B, both 6.0.0 versions with matching everything (well, as best I can tell).

So I export a template T from system A as XML, then import into system B, and it failes, claiming the error as below.

This error is generated even if I export from system A, make a trivial change in system A's live copy with the UI, then import the XML -- the exact XML just exported. So there is something it is happy with internally but not on import.

This template I'm calling T depends on another I'll call P. I have verified that all hosts that use T also have template P, so as it merges in there should be no problem finding the right trigger. Note these are prototype triggers in T depending on a non-prototype trigger in P (I have no idea if that matters).

I can export P, make a trivial GUI change, and import P and it works. P has no dependences to other templates.

This worked fine in version 4; I realize that was a long time ago. But I can find no change documented that should break it.

Am I missing something?

I'm attaching a copy of the templates if anyone wants to actually try them. These are as exported from a working system.

Any idea what I'm doing incorrectly?

Trigger prototype "DNS via {#DNS_PROTOCOL} to {#DNS_HOST} too slow ({ITEM.LASTVALUE1})" depends on trigger "Unavailable by Ping Check", which does not exist. [zabbix.php:22 → require_once() → ZBase->run() → ZBase->processRequest() → CController->run() → CControllerPopupImport->doAction() → CApiWrapper->__call() → CFrontendApiWrapper->callMethod() → CApiWrapper->callMethod() → CFrontendApiWrapper->callClientMethod() → CLocalApiClient->callMethod() → CConfiguration->import() → CConfigurationImport->import() → CConfigurationImport->processDiscoveryRules() → CConfigurationImport->processTriggerPrototypeDependencies() in include/classes/import/CConfigurationImport.php:1492]

[Linwood]

Hmmm... I may have found the issue....

If I export both the template and the dependency template in the same XML file, it works. This despite the dependency template is already in the system, named properly and not different from the import.

Is that the expected behavior?

So T depends on P. If I export T, change T in the GUI (just to generate a difference), and import T it fails (this all on one same system).

If I do exactly the same thing but export T and P together, the import succeeds. That just seems bizarre.

[Linwood]

Huh, yeah, that isn't a very helpful explanation, is it?

Can you share your package.json file?

I'm sorry, I do not know what that file is. Is that related to installing from the pre-packaged versions? I built zabbix from sources.

[tim.mooney]

Good find regarding exporting both templates together.

Does the behavior change at all if you use JSON or YAML instead of XML, for the export/import between your 6.x systems?

[Linwood]

All three fail the same way (which is a good thing, the packaging technique should be transparent).

So the only workaround I can find is to always export the dependent item at the same time. Which is a real pain if you do not KNOW it is dependent until it fails. What I would do in the past is export each template to a text file from source and destination system using the API in perl, then do a comparison (Winmerge), and on the out-of-date system import that template. Now I may need to go back and export again to include the dependent one when it fails (just concatenating the files does not work, and manually editing to combine is harder than exporting and FTP'ing over I think).

But to me this is just broken. Is this topic considered the place to report bugs? Years ago there was a bug database, but I see this forum says report bugs here?

[eithor]

According to release notes this should be fixed in 6.0.5

[Linwood]

According to release notes this should be fixed in 6.0.5

Good to know, thanks. I upgraded but did not notice that in the release notes.