[BUG] --ls-vlan and quads-web vlans display incorrect values

[sadsfae]

It appears we may not be reclaiming vlan associations cosmetically, but functionally everything works.

quads --define-cloud --cloud cloud48 --description "RHEL Perf EL7 vs EL10" --cloud-owner yinsong --cloud-ticket 3976 - vlan 605

This applies and provisions:

-=>>python /usr/lib/python3.12/site-packages/quads/tools/ls_switch_conf.py --cloud cloud48
INFO - Cloud qinq: 0
INFO - Interface em1 appears to be a member of VLAN 1570
INFO - Interface em2 appears to be a member of VLAN 1571
INFO - Interface em3 appears to be a member of VLAN 1572
INFO - Interface em4 appears to be a member of VLAN 1573
INFO - Interface em5 appears to be a member of VLAN 605

However vlan associations page via quads-web lists it empty

QUADS CLI lists the old tenant that had this vlan:

-=>>quads --ls-vlan | grep 605
605: cloud06

This tenant cloud doesn't actually exist anymore.

[sadsfae]

@grafuls a little more on this bug, above cloud06 which was the previous owner of VLAN605 and didn't relinquish it according to --ls-vlan still seems to be set active in the database.

I believe this may have been a symptom of #545 that is resolved here in 2419f3a and also tangentially related to this change too: 6a0d118

If we look at the last assignment in environment cloud06 in the database, the assignment is still set as active

quads=# select * from assignments where cloud_id = 7;
 id | active | provisioned | validated |           description            | owner | ticket | qinq | wipe |                                         
                             ccuser                                                                      | cloud_id | vlan_id |         created_at 
        
----+--------+-------------+-----------+----------------------------------+-------+--------+------+------+-----------------------------------------
---------------------------------------------------------------------------------------------------------+----------+---------+--------------------
--------
  4 | f      | t           | t         | Forester Dev2                    | lzap  | 3676   |    0 | t    | \x80055d942e                            
                                                                                                         |        7 |         | 2024-08-20 16:30:52
.340346
 49 | t      | t           | t         | OCP Multi-Cluster NW Perf 2/2 v2 | jlema | 3879   |    0 | f    | \x8005953c000000000000008c1673716c616c63
68656d792e6578742e6d757461626c65948c0b4d757461626c654c6973749493945d948c0872736576696c6c619461859452942e |        7 |       5 | 2024-09-10 16:44:55
.287929
(2 rows)

The vlan clear fix + find-free-cloud fix landed 2024-11-05 so it was likely updated in our production shortly after that.

Cloud06 OCP Multi-Cluster NW Perf 2/2 v2 was provisioned on 2024-11-04 and didn't expire until 2024-11-24:

3030| start=2024-11-04T12:15, end=2024-11-24T22:00, cloud=cloud06

Therefore I think it's possible this is fixed already but this cloud never got retroactively set to being inactive in the database, as that was required after this fix as I recall.

I've now set the old, expired assignment for cloud06 to false:

quads=# update assignments set active = false where id = 49;
UPDATE 1

Now quads --ls-vlan actually reports the correct ownership of cloud48 for being attached to VLAN605

-=>>quads --ls-vlan | grep cloud48
605: cloud48

Also quads-web reports this as well.

I think this may not be a bug but we should audit all assignments and ensure any expired assignments are still not set active