[READY] Reallocate switches

[kylerisse]

Fixed #775

Description of PR

This is a mass renaming of all the switches per work party 1. It also disables the data validation for switch noise level as that will be going away.

Previous Behavior

• switches had previous IDs
• noise level data validation only allowed for specific values

New Behavior

• switches have new IDs supplied by @davidelang
• noise level data validation now passes with any value, no longer strict

Tests

1. spot checked a couple of entries in the output
2. ran nix build -L .#checks.x86_64-linux.pytest-facts to validate TSV contents still valid (found noise level issue and modified behavior.
3. ran nix build -L .#checks.x86_64-linux.perl-switches and verified the switch configurations were generated and script exit 0
4. Asking @davidelang to check this PR and approve if it all looks good.

[davidelang]

@owendelong this looks good to me. There are two switches we need to replace #5 and #51 (formerly #54)
I think you probably want to set some default configs for the spares, but I don't know what you would want to do with them (1/2 for rooms for each side? set some as idf or booth? don't care because you will reassign them when they go to get used??)

[owendelong]

I had previously set them all up as cfRoom just as a placeholder and to minimize the likelihood of conflict if they got plugged in to a switch port in the NOC.

[owendelong]

On cursory look, this seems sane. We should be prepared for "interesting" flash results.

I'll try to catch anything glaring during the sticker generation process on its next run.

[davidelang]

We will also need to move fiber cards between switches. David Lang

…

On Sun, 22 Sep 2024, Owen DeLong wrote: Date: Sun, 22 Sep 2024 15:59:57 -0700 From: Owen DeLong ***@***.***> Reply-To: socallinuxexpo/scale-network ***@***.***> To: socallinuxexpo/scale-network ***@***.***> Cc: David Lang ***@***.***>, Mention ***@***.***> Subject: Re: [socallinuxexpo/scale-network] [READY] Reallocate switches (PR #779) @owendelong commented on this pull request. On cursory look, this seems sane. We should be prepared for "interesting" flash results. I'll try to catch anything glaring during the sticker generation process on its next run.