fix(ingester): don't clear a cluster's scope oneof when building a VirtualMachine - #107
Closed
ldrozdz93 wants to merge 1 commit into
Closed
fix(ingester): don't clear a cluster's scope oneof when building a VirtualMachine#107ldrozdz93 wants to merge 1 commit into
ldrozdz93 wants to merge 1 commit into
Conversation
…rtualMachine
VirtualMachine(cluster=..., site=...) filled the cluster's scope_site
whenever HasField("scope_site") was False. Cluster.scope is a oneof, so
that guard is also False when the caller already scoped the cluster to a
SiteGroup, Location or Region — and CopyFrom then silently cleared it.
Guard on WhichOneof("scope") instead: the shortcut still fills an
unscoped cluster, but leaves an already-scoped one alone.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Coverage Report
|
||||||||||||||||||||||||||||||||||||||||
Contributor
There was a problem hiding this comment.
🟢 Ready to approve
The change corrects oneof-presence detection without altering the intended “fill when unscoped” behavior, and includes a focused regression test for the previously failing case.
This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.
Pull request overview
This PR fixes a protobuf oneof mutation bug in the ingester’s VirtualMachine(...) shortcut logic where setting cluster.scope_site could inadvertently clear an already-populated sibling scope field (e.g., scope_site_group) on the caller-provided Cluster message.
Changes:
- Tighten the guard for populating
cluster.scope_sitefromsiteby usingcluster.WhichOneof("scope")instead ofcluster.HasField("scope_site"). - Add a regression test ensuring an existing
Cluster.scope_site_groupis preserved when building aVirtualMachinewith asite.
File summaries
| File | Description |
|---|---|
netboxlabs/diode/sdk/ingester.py |
Prevents clearing sibling scope_* fields in the Cluster.scope oneof when applying the VM’s site shortcut. |
tests/test_ingester.py |
Adds a regression test covering the “cluster already scoped to SiteGroup” case. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 0
- Review effort level: Low
We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
VirtualMachine(cluster=…, site=…)writesscope_siteinto the caller'sClustermessage.Cluster.scopeis a protobufoneof, so that write silently deletes whatever scope the caller had already set — a SiteGroup, Location or Region.The guard was
not cluster.HasField("scope_site"), which isFalsewhile a sibling of the oneof holds the scope. So "unset" reads as true even though the cluster is already scoped, andCopyFromclears it.Fix
Guard on
WhichOneof("scope")instead. This is a strict tightening of the old check — an unscoped cluster is still filled from the VM's site, an already-scoped one is left alone.Why it matters downstream
The vCenter integration scopes a Cluster with a SiteGroup when its ESXi hosts span multiple NetBox Sites. Building any VM in that cluster replaced the SiteGroup with that VM's own Site, so the emitted payload carried two contradictory copies of the same Cluster: the root entity with the mutated
scope_site, and the nesteddevice.clusterref with the correctscope_site_group. The root entity is the one that creates/updates the Cluster in NetBox, so the wrong value won — and which Site won depended on which VM happened to be built first.Measured on
nbl-vmware-vcenter, multi-site fixture, no integration code changed:clusterdevice.clusterscope_site: DefaultSitescope_site_group: SiteGroup-MixedTagClusterscope_site_group: SiteGroup-MixedTagClusterscope_site_group: SiteGroup-MixedTagClusterVerification
pytest tests/— 214 passed, including a new regression test;ruff check netboxlabs/ tests/clean.test_virtual_machine_instantiation_with_cluster_without_sitestill passes, so the fill-when-unscoped shortcut is unchanged.worker-cli --dry-run, released SDK vs this branch: 144 entities, identical output. Single-site clusters still receivescope_site.nbl-vmware-vcentersuite on this branch: 124 passed, 2 failed. Both failures are golden files that currently record the mutated scope (duplicate IPs across sites create per-site VRFs,mixed site tags produce DefaultSite for untagged hosts); they will be regenerated on the integrations side.Not in this PR
ingester.pyis generated, so the same guard needs to go into the generator or the next regeneration will revert it. Suggested general form: if a shortcut's target field belongs to a multi-member oneof, guard onWhichOneof(<oneof>), otherwiseHasField(<field>). Today that rewrites exactly 1 of the 20 shortcut writes, and it pre-empts the same bug forIPAddress.assigned_object,MACAddress.assigned_object,WirelessLAN.scope,VLANGroup.scope,Prefix.scope,Service.parent_object,InventoryItem.componentandCustomFieldValue.value.IPAddress(assigned_object_vm_interface=…, device=…)raisesValueError: Protocol message VMInterface has no "device" field—VMInterfacelinks viavirtual_machine, so that shortcut targets a field that does not exist on the message.