Add hp_procurve_show_interfaces_status

[julmanglano]

ISSUE TYPE

• New Template Pull Request

COMPONENT

hp_procurve, show interfaces status

SUMMARY

Adds a new template for the HP/Aruba ProCurve show interfaces status
command. The output is a fixed-width table with columns Port / Name /
Status / Config-mode / Speed / Type / Tagged / Untagged.

The Ports state holds five row-shape rules to handle the variants the
device emits:

• full row: all 8 columns populated
• name + status + tagged/untagged (no config/speed/type — e.g. trunks)
• status + config + speed + type + tagged/untagged (no Name)
• status + config + tagged/untagged (no Name/Speed/Type)
• status + tagged/untagged only

Two fixtures:

• show_interfaces_status.{raw,yml} — standalone switch with port
  names like A1, A8 and truncated names (HP's 10-char Name column
  cuts off long descriptions with ...).
• show_interfaces_status2.{raw,yml} — 84-row stacked switch with
  ports like 1/1, plus trunked-port names that get truncated mid-name
  to the form 1/28-... (the 8-char Port column truncating
  1/28-Trk1).

The PORT regex is [a-zA-Z0-9\-/.]+ — / for stacked port format,
. for truncation indicator.

Cross-vendor capture-group naming aligned with existing
*_show_interfaces_status templates (PORT, NAME, STATUS, CONFIG_MODE,
SPEED, TYPE, VLAN_TAGGED, VLAN_UNTAGGED).

Index entry inserted at the correct length-sorted position within the
hp_procurve block.

[mjbear]

@julmanglano
Rather than have to handle truncated port descriptions, maybe there's a command that provides more verbose or detailed output that would include the full port description.

Thoughts?

[matt852]

One suggestion, along with @mjbear's comment:

Drop the ? on the inter-column whitespace. Non-greedy \s+? between two \S-style captures is semantically identical to \s+, and \s+ is the dominant convention across the repo's show_interfaces_status templates. In the Ports state:

-  ^\s+${PORT}\s+?${NAME}\s+${STATUS}\s+?${CONFIG_MODE}\s+?${SPEED}\s+?${TYPE}\s+${VLAN_TAGGED}\s+${VLAN_UNTAGGED}\s*$$ -> Record
-  ^\s+${PORT}\s+?${NAME}\s+${STATUS}\s+${VLAN_TAGGED}\s+${VLAN_UNTAGGED}\s*$$ -> Record
-  ^\s+${PORT}\s+${STATUS}\s+?${CONFIG_MODE}\s+?${SPEED}\s+?${TYPE}\s+${VLAN_TAGGED}\s+${VLAN_UNTAGGED}\s*$$ -> Record
-  ^\s+${PORT}\s+${STATUS}\s+?${CONFIG_MODE}\s+${VLAN_TAGGED}\s+${VLAN_UNTAGGED}\s*$$ -> Record
+  ^\s+${PORT}\s+${NAME}\s+${STATUS}\s+${CONFIG_MODE}\s+${SPEED}\s+${TYPE}\s+${VLAN_TAGGED}\s+${VLAN_UNTAGGED}\s*$$ -> Record
+  ^\s+${PORT}\s+${NAME}\s+${STATUS}\s+${VLAN_TAGGED}\s+${VLAN_UNTAGGED}\s*$$ -> Record
+  ^\s+${PORT}\s+${STATUS}\s+${CONFIG_MODE}\s+${SPEED}\s+${TYPE}\s+${VLAN_TAGGED}\s+${VLAN_UNTAGGED}\s*$$ -> Record
+  ^\s+${PORT}\s+${STATUS}\s+${CONFIG_MODE}\s+${VLAN_TAGGED}\s+${VLAN_UNTAGGED}\s*$$ -> Record

[julmanglano]

Thanks @mjbear — the truncation in show interfaces status is a stacked-switch thing. HP truncates the 8-char Port column when port names go over 8 chars (1/28-Trk1 → 1/28-...), so without tolerating the literal ... the parser errors on every trunk-member row — and we lose Up/Down, speed, duplex, and VLAN for those ports. There's no other command that gives that per-port operational state.

For trunk membership, show trunks is the cleaner source (port + group + LACP/etc.) and hp_procurve_show_trunks.textfsm is already upstream — but it's a complement to show interfaces status, not a replacement. It doesn't carry operational state for the member ports.

So the tolerance is keeping data that lives only in this command. Worth keeping unless you see a downside?

[julmanglano]

Thanks @matt852 — applied. Replaced \s+? with \s+ across the 4 record rules in the Ports state. Targeted parser tests + meta tests all green.

[mjbear]

If this command provides output others don't then it's fine to keep it.

I removed a bunch of duplication to make the newly added test data succinct.

[julmanglano]

Thanks @mjbear — pulled the clean up, tests still green.

[mjbear]

I had one last item that caught my eye. For this simple output we could have all the rules in the Start state. The benefit is less duplicate patterns in the template.

(Note: I made these changes.)

[julmanglano]

Thanks @mjbear — pulled the consolidation, tests still green.

[matt852]

One additional optional finding from the AI agent review for possibly dropping a couple lines that show as unused.

Two row-shape rules in the Start state aren't exercised by either fixture. Specifically the rules at lines 13 and 15 of hp_procurve_show_interfaces_status.textfsm:

In ntc_templates/templates/hp_procurve_show_interfaces_status.textfsm, the Start state currently includes:

   ^\s+${PORT}\s+${NAME}\s+${STATUS}\s+${CONFIG_MODE}\s+${SPEED}\s+${TYPE}\s+${VLAN_TAGGED}\s+${VLAN_UNTAGGED}\s*$$ -> Record
-  ^\s+${PORT}\s+${NAME}\s+${STATUS}\s+${VLAN_TAGGED}\s+${VLAN_UNTAGGED}\s*$$ -> Record
   ^\s+${PORT}\s+${STATUS}\s+${CONFIG_MODE}\s+${SPEED}\s+${TYPE}\s+${VLAN_TAGGED}\s+${VLAN_UNTAGGED}\s*$$ -> Record
-  ^\s+${PORT}\s+${STATUS}\s+${CONFIG_MODE}\s+${VLAN_TAGGED}\s+${VLAN_UNTAGGED}\s*$$ -> Record
   ^\s+${PORT}\s+${STATUS}\s+${VLAN_TAGGED}\s+${VLAN_UNTAGGED}\s*$$ -> Record

I confirmed this by deleting both rules and re-running the scoped tests — all 5 still passed with identical parsed output, so neither rule fires against the current .raw fixtures.

Recommended fix:

• Option A — drop the two unused rules (the diff above). Validated locally; parsed output is unchanged.
• Option B — keep both rules and add one fixture row each that exercises them. Your PR body names both variants ("name + tagged/untagged, no config/speed/type — e.g. trunks" and "status + config + tagged/untagged, no Name/Speed/Type"), so if you've seen them in real device output, dropping a representative line into one of the .raw files and regenerating the matching .yml (poetry run python cli.py gen-yaml-folder -f tests/hp_procurve/show_interfaces_status) would cover them.

Why

The project standard is that permissive constructs and fallback rules must be justified by test data exercising every branch — anything that can't be triggered by a fixture either needs the fixture or needs to be tightened. Option A is the safer cleanup if those variants haven't been seen in the wild; Option B preserves your stated intent if they have.

Thanks!

[julmanglano]

Thanks @matt852 —

Probed on hp_procurve devices and both shapes turned up on real device output:

• Shape 13 (port + name + tagged + untagged, no config/speed/type) — hit on 3 devices. Typical row: a Down port with a name set; the firmware blanks the config/speed/type columns because nothing has negotiated yet. Example: 1/52 link to... Down No 1.
• Shape 15 (port + status + config + tagged + untagged, no speed/type) — hit on 3 devices. Typical row: a Down port with no name but an explicit Auto config-mode; speed/type stay blank until link comes up. Example: D1 Down Auto No 10.

So both rules represent real device behaviour. Went with Option B and added two fixtures sanitised from the captures:

• show_interfaces_status3.raw — exercises shape 13 (1/52 row).
• show_interfaces_status4.raw — exercises shape 15 (D1–D24 rows).

Yml regenerated for both via textfsm; line 13 fires on 1/52, line 15 fires on the D1–D24 block. Parser tests + meta tests all green locally.

Pushed.