Deprecate the assignment of VLANs directly to sites

[jeremystretch]

Proposed Changes

Deprecate the ability to assign a VLAN to a site rather than a VLAN group. This functionality will not break immediately, but will be removed in a future release.

Justification

The recommended approach to VLAN management is to create a VLAN group scoped to the site, and assign VLANs to that group.

Impact

The UI will warn users of VLANs with direct site assignments, and discourage new site assignments.

[sleepinggenius2]

As it looks like the decision has been made to move forward with ultimately removing the site field from the VLAN model (which I do support), I am adding my comment from #19707 to this issue as well:

One other challenge I see is that when you navigate to a site in the UI, it currently only lists related VLANs that are directly associated with that site, not a VLAN group that is scoped to that site. Likewise, the VLAN filter form only allows searching for VLANs that are directly associated with a site. If you remove the site field from the VLAN object, I would request that the functionality that used it, like the two previous examples, be extended to support VLAN Groups that are scoped to a Site as well. I would love to see that functionality be extended to the other scope types, but I can understand where that would probably be a different feature request.

We try to use a consistent naming and numbering scheme for VLANs at each site. A common task our engineers have is to assign a management IP for a new device at a site. Today that can be relatively easily done by filtering the VLANs by site and VID or name, then clicking on the prefix and adding a new IP address. I just tested what that would look like with adding a VLAN Group into that process and it is a lot more cumbersome.

[misch42]

I automation I use jinja templates with the device.site.vlans.all() function to get all vlans that are relevant for the specific device. How to replace this function in the jinja templates?