RFE: Support other switches besides Juniper.

[smalleni]

As we make further improvements to QUADS and possible have a base Networking Class that is inherited by classes specific to vendors like Juniper.py, Cisco.py as some of the other issues point out, it would be helpful to have a YAML file where we define the switch port to machine mappings that is consumed by QUADS to operate in a Lab Agnostic fashion when making switch config changes. This would make QUADS readily portable to BAGL.

[kambiz-aghaiepour]

I had originally thought to do just that. The current switch mappings are not in the yaml but moving them back is not out of scope. I will have to consider where all the dependencies are though (e.g. wiki regeneration and instackenv.json file generation).

[sadsfae]

Adding to this, the mappings are done in a way that it doesn't matter anyway what the switch technology is - only that the port mappings are accurate.

For example:

# cat /etc/lab/ports/b10-h21-r620.rdu.openstack.engineering.example.com 
em1,b8:ca:3a:63:86:58,10.12.67.239,switch-type,xe-0/0/7:2
em2,b8:ca:3a:63:86:5a,10.12.67.239,switch-type,xe-0/0/7:3

The xe-* could easily be named something different above. Also of note is we have a stub field called switch-type. This was put in place for future enhancement to break out to different vendor types but isn't currently utilized anywhere yet.

One future enhancement we've discussed that I'd really like to see is a kind of discovery tool that you can point towards a switch with adequate credentials and it will generate your /etc/lab/ports/ files automatically. You should have the option to feed it the port(s) you want to have participate in QUADS provisioning or have the option to let it simply setup a new environment for you. This is currently done manually, we'd like to have a test switch to develop this on.

[smalleni]

Got it. But as of now the switch commands are hardcoded for Junos correct?

They are not hard-coded for any kind of switch technology, Juniper just happens to use xe so that's what we adopted but it doesn't actually translate to anything Juniper-specific on the backend.

It currently works with Juniper simply because we only have Juniper switches. If we had Cisco, Force10 or anything else it would also work. The key here is that each ports file is specific to only one host not a switch type so it can be updated to reflect what it's currently plugged into (even if it plugs into different switch types per port).

Because each machine has it's own /etc/lab/ports/MACHINE file if it was using another technology it would not matter.

Knowing what Force10 uses an equivalent server connected to a Force10 switch might look like this for that host.

em1,b8:ca:3a:63:86:58,10.12.67.239,switch-type,TenGigabitEthernet-0/22/7:2
em2,b8:ca:3a:63:86:5a,10.12.67.239,switch-type,TenGigabitEthernet-0/23/7:3

In order to support other switch types we'd just need to populate the switch-type field you see above so that QUADS knows to utilize different expect tooling to perform VLAN port changes.

We have a stub here where we'd start to do this when we need to support other vendors (or more importantly when we have equipment we can test against).

https://github.com/redhat-performance/quads/blob/master/bin/move-and-rebuild-host.sh#L232