You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It turns out that this is not actually an API-speciifc issue! The same behavior can be seen via the UI, though the dynamic rendering of the UI form obscures this:
Begin creating a new VMInterface via the UI
Set mode to access so that the Untagged vlan field appears, and select a VLAN from the dropdown.
Clear out the mode setting (the Untagged vlan field now disappears from view, but its selection remains in effect)
Submit the form
Via your browser's developer tools, you can see that the form was submitted with an untagged_vlan value:
But the resulting VMInterface has no associated VLANs.
# Remove untagged VLAN assignment for non-802.1Q interfacesifnotself.mode:
self.untagged_vlan=None# Only "tagged" interfaces may have tagged VLANs assigned. ("tagged all" implies all VLANs are assigned.)ifself.present_in_databaseandself.mode!=InterfaceModeChoices.MODE_TAGGED:
self.tagged_vlans.clear()
This appears to have been intentionally added in NetBox via netbox-community/netbox#5360, but I agree that this is unintuitive for the REST API, and perhaps we can come up with a better way to solve that problem.
Environment
Steps to Reproduce
Expected Behavior
The untagged VLAN is set in the object
Observed Behavior
VLAN is not set in the virtual interface
Workaround
Set the following data:
Acceptance Criteria
mode
is not set to properly accept the untagged VLAN attribute, and a message in response to that effect.Requirements
mode
anduntagged_vlan
are incompatibleuntagged_vlan
fieldThe text was updated successfully, but these errors were encountered: