fix(VMware): resolve cluster_scope_id_relation to the scoped object

[tfoks]

With cluster_scope_type_relation and cluster_scope_id_relation configured, the VMware source passed the configured scope id to the cluster as a plain string. NBCluster only accepts a Site, SiteGroup, Location or Region object as scope_id, so every cluster failed with:

ERROR: Invalid data type for 'scope_id' (must be one of [<class '...NBSite'>, <class '...NBSiteGroup'>, <class '...NBLocation'>, <class '...NBRegion'>]), got: '1'

The cluster then got the new scope_type but no scope.

Changes:

• module/sources/vmware/connection.py: look up the object of the configured scope type by its NetBox id and use it as scope_id. The scope type must be one of dcim.site, dcim.sitegroup, dcim.location or dcim.region, and the id must be a decimal number. If either check fails, or no object with that id exists, log one error and leave the scope unset.
• module/sources/vmware/config.py, settings-example.ini: note that the cluster scope options need NetBox 4.2 or newer and are ignored below that.
• tests/test_cluster_scope.py: one test checks that a configured SiteGroup id is resolved to the SiteGroup object. Others check that a missing id, a non-numeric id, a superscript digit (³) or an unsupported scope type (dcim.device) sets neither scope type nor scope and logs one clear error.

Tested against NetBox 4.7.2 with a vCenter source and cluster_scope_type_relation: .* = dcim.sitegroup, cluster_scope_id_relation: .* = 1: all clusters are scoped to the site group, and the dry-run logs no errors. pytest: 378 passed, 8 skipped (vcsim installed).

🤖 Generated with Claude Code

[semx]

Reproduced it against NetBox 4.7.2 with the vcsim captures: on development every run logs Invalid data type for 'scope_id' and NetBox answers Please select a sitegroup., with this branch the cluster gets the site group and the second run changes nothing. A missing id logs a clear error, good.

Two things before merge:

• str(scope_id).strip().isdigit() is true for Unicode digits like ³, and int() then raises and stops the whole run. isdecimal() avoids that.
• The non-numeric id and the unsupported type branches have no tests. Also NetBoxMappings().get() resolves any netbox-sync type, so dcim.device passes the first check and ends in two Invalid data type errors; checking against the four cluster scope types would give one clear message.

Optional: mention in the option description that the scope options need NetBox 4.2 or newer, below that they're ignored silently.

[tfoks]

Thanks for reproducing it. Both points are addressed:

• isdecimal() instead of isdigit(). A test with ³ covered the crash.
• The scope type is now checked against dcim.site, dcim.sitegroup, dcim.location and dcim.region. dcim.device now logs one Unsupported scope type 'dcim.device' ..., must be one of: ... instead of the two Invalid data type errors.
• New tests for a non-numeric id, ³ and an unsupported type. Each checks that no scope is set and that the expected error is the only one logged. The ³ and dcim.device tests fail on the previous commit.
• I added the NetBox 4.2 note to both option descriptions and regenerated settings-example.ini.

[semx]

Thanks, looks good now. I ran it against NetBox 4.7.2 with dcim.device, ³ and an id that doesn't exist: each one just logs an error and the cluster keeps no scope. On the previous commit ³ took the whole run down with a ValueError, so that was worth catching.