[BUG] In some cases VLAN ID's don't seem to be properly reaped and referenced for future assignments correctly

[sadsfae]

It appears that as of quads-2.1.0-20241101.noarch or 3861f54 --vlan ID's that were previously part of expired assignments still show up as being used.

# quads --ls-vlan | grep -E "604|605"
604: cloud50
605: cloud51

However, I am still able to assign them to a new assignment (in this case 2 x --no-wipe assignments) without error but they actually don't attach according to quads --ls-vlan

quads --define-cloud --cloud cloud05 --description "OCP Multi-Cluster NW Perf (1/2) v2" --cloud-owner jlema --cc-user
s "rsevilla" --vlan 604 --cloud-ticket 3878
quads --define-cloud --cloud cloud06 --description "OCP Multi-Cluster NW Perf (2/2) v2" --cloud-owner jlema --cc-user
s "rsevilla" --vlan 605 --cloud-ticket 3879

Side Effects

I think as a side-effect, we also don't get the future_initial_message email notification on --define-cloud, though I think the error is likely hidden somewhere or not visible.

Also, our JIRA ticket update doesn't break down the additional VLAN messaging either respective of the VLAN added.

Workaround but with Issues

I am able to pass the assignment(s) by stripping the VLAN off and back on to the new environment.

# quads --mod-cloud --cloud cloud50 --vlan none
Cloud modified successfully
# quads --mod-cloud --cloud cloud51 --vlan none
Cloud modified successfully
# quads --mod-cloud --cloud cloud05 --vlan 604
Cloud modified successfully
# quads --mod-cloud --cloud cloud06 --vlan 605
Cloud modified successfully

Lastly, even after manually removing and re-assigning the right VLANS to two new no-wipe assignments the /vlans wiki page does not reflect this mapping.

After they are released I have to re-apply again the vlan association for this to work.

#quads --ls-vlan
604: Free
605: Free

# quads --mod-cloud --cloud cloud05 --vlan 604
Cloud modified successfully

# quads --mod-cloud --cloud cloud06 --vlan 605
Cloud modified successfully

# quads --ls-vlan
604: cloud05
605: cloud06

After this I see the correct association, but only after the clouds were released, otherwise it neither actually takes hold nor is it persistent through the pre-release phases.

[sadsfae]

Related I think, the vlan gets dropped once the cloud is released:

-=>>flock -n /tmp/notify.lock -c "quads --notify"
=============== Initial Message
Notifications sent out.

-=>>quads --ls-vlan | grep 604
604: Free

-=>>date
Mon Nov  4 05:25:03 PM UTC 2024

-=>>python3 /usr/lib/python3.12/site-packages/quads/tools/verify_switchconf.py --cloud cloud55
INFO - Host: f30-h15-000-r640.example.com
WARNING - Interface et-0/0/21:3 not using QinQ_vl1644
INFO - Host: f31-h01-000-r640.example.com
WARNING - Interface et-0/0/16:1 not using QinQ_vl1644
INFO - Host: f31-h02-000-r640.example.com
WARNING - Interface et-0/0/16:3 not using QinQ_vl1644
INFO - Host: f31-h03-000-r640.example.com
WARNING - Interface et-0/0/17:1 not using QinQ_vl1644
INFO - Host: f31-h06-000-r640.example.com
WARNING - Interface et-0/0/18:1 not using QinQ_vl1644
INFO - Host: f31-h07-000-r640.example.com
WARNING - Interface et-0/0/18:3 not using QinQ_vl1644

-=>>python3 /usr/lib/python3.12/site-packages/quads/tools/ls_switch_conf.py --cloud cloud55
INFO - Cloud qinq: 0
INFO - Interface em1 appears to be a member of VLAN 1640
INFO - Interface em2 appears to be a member of VLAN 1641
INFO - Interface em3 appears to be a member of VLAN 1642
INFO - Interface em4 appears to be a member of VLAN 1643
INFO - Interface em5 appears to be a member of VLAN 604