Handle/add increased logging for unsupported object types

[skupjoe]

Firstly, hello and thank you for the fantastic software.

Similar to issues #76 and #103, we were experiencing an issue with our vspheredb deployment where (in our new vCenter network/environment, only) the vspheredb object table was not being generated, yet all other tables were being produced correctly, and no issues were being reported in the logs, even when executing the initial sync via icingacli vspheredb daemon run --debug --trace.

After debugging the code in the fashion mentioned here, I noticed that we were seeing SQLSTATE[01000]: Warning: 1265 Data truncated errors, and so there were violations coming from the DB side.

Got invalid NetString data: 'Storing object[?@"e?G\\U????>|?Q??"] failed: SQLSTATE[01000]: Warning: 1265 Data truncated for col[..] truncated 1590 bytes [..] logger.log","params":["debug","Task \"Managed Object References\" took 3571.14ms on 172.16.11.62"]},

After adding further statements to print out the contents of the $properties array for each object, I noticed an OpaqueNetwork object type that wasn't covered in the ENUM() constraint for the object_type column, which ultimately was causing my error.

Further research shows that this object type is related to NSX, which we have deployed in our new vCenter 6.7 environment.

I've submitted PR #166 to fix this immediate bug & support NSX OpaqueNetwork object types.

I'm additionally requesting for additional Logger:: error and debug declarations to be added in the try/catch for the db commit functions to better bring to light these types of exceptions when they occur. As the VMware ecosystem expands, there will undoubtedly be other unsupported object types like this that get introduced in the future.

Also, I would lastly request that the SyncManagedObjectReferences runner be refactored to better handle such SQL commit violations. In my opinion, it should have still worked to generate an object table with at least the supported object types, but it appears to behave as all-or-nothing for these situations, currently.

Your Environment

• VMware vCenter®/ESXi™-Version: 6.7u3g
• Version/GIT-Hash of this module: Master cc39b00
• Icinga Web 2 version: 2.7.3-1.buster
• Operating System and version: Debian 10
• Webserver, PHP versions: 7.3

[Thomas-Gelf]

[Thomas-Gelf]

@skupjoe: the problem here is that (in this case) it silently eats DB errors instead of throwing an error. In addition to this, there was an error in the scheduler. That way the next 1-2 tasks fired even if the former one failed. I'll immediately push a related fix.

There is one question, you mentioned Got invalid NetString data: ... -> this shouldn't happen at all, it has been fixed a long while ago. At least it SHOULD have been fixed. Are you sure that you experienced this error with the module version you mentioned?