Deleting vlan deployed on interface causes Server Error #4613

Originally created by @netixx on GitHub (Mar 2, 2021).

Environment

Python version: 3.8.7
NetBox version: 2.10.4

Steps to Reproduce

Create a VLAN (specify VID and VLAN name, no specific configuration needed)
Use this vlan as access on a interface: select an interface in a device, configure 802.1q mode (say access), select previously created vlan in "Untagged VLAN". Please note it also works when using the tagged option.
Delete the previously created VLAN (select VLAN, delete, confirm).
Go back to the page of the interface => the Server Error occurs.

Expected Behavior

Option A: prevent VLAN from being delete as configuration of interface depends on it.
Option B: delete the vlan from the configuration of the interface when the vlan is deleted from NetBox.

Observed Behavior

Following error occurs when browsing the interface:

<class 'ipam.models.VLAN.DoesNotExist'>

VLAN matching query does not exist.

Python version: 3.8.7
NetBox version: 2.10.4

I would favor option B, as from a user standpoint, deleting a vlan should remove this vlan on all interfaces.
However, dealing with access interfaces could be more tricky...

Originally created by @netixx on GitHub (Mar 2, 2021).  ### Environment * Python version: 3.8.7 * NetBox version: 2.10.4  ### Steps to Reproduce 1. Create a VLAN (specify VID and VLAN name, no specific configuration needed) 2. Use this vlan as access on a interface: select an interface in a device, configure 802.1q mode (say access), select previously created vlan in "Untagged VLAN". Please note it also works when using the tagged option. 3. Delete the previously created VLAN (select VLAN, delete, confirm). 4. Go back to the page of the interface => the Server Error occurs.  ### Expected Behavior Option A: prevent VLAN from being delete as configuration of interface depends on it. Option B: delete the vlan from the configuration of the interface when the vlan is deleted from NetBox.  ### Observed Behavior Following error occurs when browsing the interface: ``` <class 'ipam.models.VLAN.DoesNotExist'> VLAN matching query does not exist. Python version: 3.8.7 NetBox version: 2.10.4 ``` I would favor option B, as from a user standpoint, deleting a vlan should remove this vlan on all interfaces. However, dealing with access interfaces could be more tricky...

adam added the type: bug pending closure labels 2025-12-29 18:38:16 +01:00

adam closed this issue

adam commented

@xkilian commented on GitHub (Mar 2, 2021):

I would kindly disagree. Deleting a vlan that is used should not be allowed.
In a switch or router you cannot delete a vlan if it is assigned. Least surprise. Deleting a vlan that is used could have all kinds of funky side effects, and implies that changes are also done beyond the original intention. Trunk port that only has vlan X on it, access ports, prefixes assigned to vlans, etc.
Of course you have to find all the places the vlan is assigned and unassign them, which is a hassle, but it is a change which should be tracked.

@xkilian commented on GitHub (Mar 2, 2021): I would kindly disagree. Deleting a vlan that is used should not be allowed. In a switch or router you cannot delete a vlan if it is assigned. Least surprise. Deleting a vlan that is used could have all kinds of funky side effects, and implies that changes are also done beyond the original intention. Trunk port that only has vlan X on it, access ports, prefixes assigned to vlans, etc. Of course you have to find all the places the vlan is assigned and unassign them, which is a hassle, but it *is* a change which should be tracked.

adam commented

@netixx commented on GitHub (Mar 2, 2021):

Our use case is mostly switching, this is why I favored option B, but as I stated, option A is the more rational choice (and more consistent with the rest of the objets).

@netixx commented on GitHub (Mar 2, 2021): Our use case is mostly switching, this is why I favored option B, but as I stated, option A is the more rational choice (and more consistent with the rest of the objets).

adam commented

@jeremystretch commented on GitHub (Mar 2, 2021):

Please expand your steps above to detail exactly how the VLAN is being created, assigned, and deleted so that someone else can attempt to reproduce the issue.

@jeremystretch commented on GitHub (Mar 2, 2021): Please expand your steps above to detail exactly how the VLAN is being created, assigned, and deleted so that someone else can attempt to reproduce the issue.

adam commented

@netixx commented on GitHub (Mar 2, 2021):

I updated my original post above.
I really didn't do anything specific to trigger this behaviour.
Please let me know if I need to provide any additionnal information or steps.

@netixx commented on GitHub (Mar 2, 2021): I updated my original post above. I really didn't do anything specific to trigger this behaviour. Please let me know if I need to provide any additionnal information or steps.

adam commented

@sdktr commented on GitHub (Mar 2, 2021):

I'd prefer option C in this- as well as other 'locked-when-in-use' cases: warn for dependencies but allow to delete anyway instead of going back to all the referenced dependent resources and delete the association 1-by-1

@sdktr commented on GitHub (Mar 2, 2021): I'd prefer option C in this- as well as other 'locked-when-in-use' cases: warn for dependencies but allow to delete anyway instead of going back to all the referenced dependent resources and delete the association 1-by-1

adam commented

@netixx commented on GitHub (Mar 11, 2021):

in the case of option C, would the vlan be removed from the interface ? or would the interface display an explicit error on the vlan field (as opposed to the server error as it is currently the case) ?

@netixx commented on GitHub (Mar 11, 2021): in the case of option C, would the vlan be removed from the interface ? or would the interface display an explicit error on the vlan field (as opposed to the server error as it is currently the case) ?

adam commented

@jeremystretch commented on GitHub (Mar 11, 2021):

Seems to be yet another caching issue. I've been able to confirm that this only occurs when caching is enabled. I'm not sure why deleting the VLAN is not invalidating the cached query.

@jeremystretch commented on GitHub (Mar 11, 2021): Seems to be yet another caching issue. I've been able to confirm that this only occurs when caching is enabled. I'm not sure why deleting the VLAN is not invalidating the cached query.

adam commented

@github-actions[bot] commented on GitHub (Apr 26, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Apr 26, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

@jeremystretch commented on GitHub (May 25, 2021):

This still needs to be addressed. Honestly, it feels like we're nearing the point where caching does more harm than good. We've had a lot of similar bugs to work around.

@jeremystretch commented on GitHub (May 25, 2021): This still needs to be addressed. Honestly, it feels like we're nearing the point where caching does more harm than good. We've had a lot of similar bugs to work around.

adam commented