Repository navigation
vmware: reuse VLANs from VLAN groups the settings name as global - #624
Open
tyderian1978 wants to merge 1 commit into
Open
tyderian1978 wants to merge 1 commit into
tyderian1978 wants to merge 1 commit into
Conversation
A VLAN in a VLAN group without a scope is never matched: get_vlan_object_if_exists() matches a grouped VLAN only when the group's scope covers the site or cluster, and takes a VLAN as global only when it has neither site nor group. Where another tool keeps the VLANs in such a group (for example filled from an IPAM, with their prefixes), every VLAN discovered in vCenter therefore got a duplicate without site or group, and the interfaces were linked to the duplicate. The vlan_group_relation_* options don't help: they only choose the group of a VLAN being created. The new option vlan_global_groups names unscoped VLAN groups whose VLANs are valid everywhere. Matching order: a VLAN of the site, a VLAN in a group scoped to the site or cluster, a VLAN in one of these groups, a VLAN with neither site nor group. A scoped group isn't made global by naming it. Unset, nothing changes.
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.
Disclaimer: AI generated, based off the work we're doing with Netbox.
What happens
A VLAN in a VLAN group without a scope is never matched by
get_vlan_object_if_exists(). A grouped VLAN matches only when the group's scope covers the site or cluster, and only a VLAN with neither site nor group counts as global. Where another tool keeps the VLANs in such a group (ours are filled from Infoblox, with their prefixes), every VLAN netbox-sync discovers gets a duplicate without site or group, and the interfaces are linked to the duplicate: we had 135 duplicates of 119 VLAN IDs. Thevlan_group_relation_*options don't help, since they only choose the group of a VLAN being created, and a single scope can't cover hosts in sites of different site groups.Fix
A new option,
vlan_global_groups: a comma separated list of VLAN groups without a scope whose VLANs are valid everywhere. Matching order becomes: a VLAN of the site, a VLAN in a group scoped to the site or cluster, a VLAN in one of these groups, a VLAN with neither site nor group. Naming a scoped group doesn't make it global. Unset, nothing changes, so matching by VLAN ID alone stays opt-in (see the discussion in #471).settings-example.iniis regenerated with-g.Tests
tests/test_vlan_global_groups.py:Three fail on
developmentwithout the change. Full suite: 616 passed, 8 skipped.Also checked end to end against vcsim and NetBox 4.7.2, with an unscoped group holding two of the VLAN IDs. Before, the interfaces stay on netbox-sync's own VLANs. After, those two interfaces move to the group's VLANs in one run, the others are untouched, no VLAN is created, and the group's VLANs keep their names (netbox-sync adds its tags, as for any VLAN it uses). A dry run against our five vCenters moves 1,674 VM interfaces onto the group's VLANs (85 VLAN IDs, each to the VLAN with the same ID) and leaves the two VLAN IDs the group doesn't have on their own VLANs.