feat: Unsupported Transceivers

[adambaumeister]

Description

In certain software versions, following an upgrade, it's observed that non-OEM Transceivers (SFPs) can become non-functional after a software upgrade. The unsupported_transceiver test fails when any such transceiver is found in output of "show system state".

Motivation and Context

If a user upgrades and is using unsupported transceivers that become unrecognized by the system, this is a potential major issue that could a severe network outage.

There are two major points up for debate before we can finish this test:

• The majority of our customers may use non-OEM SFPs, which would mean this test fails all the time. As far as I can find, there is no further way to narrow down this test to a specific software version. Is this ok?
• After looking at some real examples, there are optics that are listed in support documentation as "supported" but are not shown as "OEM" in the output of system state, so the test as implemented here would incorrectly mark them as failed. We could implement this list in code, but then we would be responsible for keeping it in sync which might not be good.

How Has This Been Tested?

• Unit tests using real - though truncated - show system state details

The tests have been run against vm-series firewalls but of course they don't have SFPs so we can't fully validate this without a live hardware lab.

Types of changes

• New feature (non-breaking change which adds functionality)

[alperenkose]

I think it's good to have this, even though the test might fail for actually supported non-OEM SFPs, we can still use it to highlight this to the user and be aware of it during the upgrade. I think we can have the logic in the wrapper tools (Ansible, XSOAR) to fail or just to warn about it. Having said that I don't think we can maintain a manually updated list of SFPs but we can test only the OEM SFPs.

[adambaumeister]

I agree @alperenkose. Maybe we should rename the test to "non-OEM transceivers" instead?

@FoSix thoughts?

[horiagunica]

Just my personal thought - but the rest of the checks are Green light -> proceed with upgrade . If we reverse the logic - this one would look odd in the same context. Since the checks are a list and we can cherry pick which ones you want - we can maybe leave it as the initial proposal (fail check in case of non-OEM transceivers) ?

[FoSix]

maybe we could do both?

• with default settings check for non-OEM transceivers, fail if any are found
• add an optional parameter that would be a list of ignored transceivers (question is in what format one should specify this list). This way we could add a possibility to ignore the ones that are supported w/o maintaining the list ourselves. One would have to of course verify the current list with the running HW. This alone is already fulfilling the check so maybe this option is pointless.

Is the non-oem, but supported list publicly available? Maybe we could download that list in the code and do some regex search on it?

[adambaumeister]

@FoSix the full list of "supported" transceivers is ONLY availalbe on the Live and requires a support login. So it's available to customers but is NOT publicly available.

I like your solution of an option to pass a list of additionally supported optics, I think that's a very clean and nice solution. I will work on it.

[adambaumeister]

As discussed, added an option to provide a list of regex that can be used as a comparison while testing for OEM optics. This allows the user to specify vendor part numbers like PAN-.* so they can specify which are supported in a scalable way.

[FoSix]

@adambaumeister I've noticed that for whatever reason the CI PR did not trigger. When I run all checks locally I get some errors: some about formatting, but the biggest one is this one:

You have to rebase with main as well, some breaking changes were merged recently.

[github-actions]

☂️ Python Coverage

current status: ✅

Overall Coverage

Lines	Covered	Coverage	Threshold	Status
953	938	98%	95%	🟢

New Files

No new covered files...

Modified Files

File	Coverage	Status
panos_upgrade_assurance/init.py	100%	🟢
panos_upgrade_assurance/check_firewall.py	98%	🟢
panos_upgrade_assurance/exceptions.py	100%	🟢
panos_upgrade_assurance/firewall_proxy.py	100%	🟢
panos_upgrade_assurance/utils.py	98%	🟢
TOTAL	99%	🟢

updated for commit: b186eba by action🐍

[github-actions]

A Preview PR in PanDev repo has been created. You can view it here.

[adambaumeister]

@FoSix I fixed that issue (was 3.11 prob), updated API docs and fixed the formatting issues. Anything outstanding here you think?

[alperenkose]

LGTM