Add hp_procurve_show_lldp_info_local-device

[julmanglano]

ISSUE TYPE

• New Template Pull Request

COMPONENT

hp_procurve, show lldp info local-device

SUMMARY

Adds a new template for the HP/Aruba ProCurve show lldp info local-device command. Captures the device's own LLDP advertisement —
chassis info, system name/description, capabilities, and management
address.

Capture groups (cross-vendor aligned with other LLDP templates):
CHASSIS_TYPE, CHASSIS_ID, SYSTEM_NAME, SYSTEM_DESCRIPTION, MODEL,
CAPABILITIES_SUPPORTED, CAPABILITIES_ENABLED, MGMT_ADDRESS_TYPE,
MGMT_ADDRESS.

SYSTEM_DESCRIPTION has two fallback rules: when the description
starts with the vendor token (ProCurve|HP|Aruba), the part-number
is captured separately into MODEL; otherwise the whole string is
captured into SYSTEM_DESCRIPTION.

CHASSIS_ID is anchored on \S.*\S rather than \S+ because
ProCurve emits the chassis MAC in two different formats depending on
firmware:

• compact dash-separated: 548028-aabbcf (stack/newer firmware)
• space-separated bytes: 54 80 28 aa bb cd (standalone/older firmware)

The two fixtures cover both formats.

The LLDP Port Information section is acknowledged but not parsed
into capture groups (it would duplicate show lldp info remote-device
output — out of scope here).

Index entry inserted at the correct length-sorted position within the
hp_procurve block (length 47, between length-48 and length-45 rows).

[matt852]

Recommendation: Changes Suggested

Thanks @julmanglano — clean PR with thoughtful test data covering both chassis-ID formats. One cross-vendor alignment suggestion before merge:

Rename CAPABILITIES_ENABLED → CAPABILITIES. The dominant LLDP/CDP convention across Cisco, Arista, Aruba AOS-CX, Brocade, Huawei, and the existing hp_procurve_show_lldp_info_remote-device_detail.textfsm is CAPABILITIES_SUPPORTED paired with plain CAPABILITIES for the enabled set. Matching the sibling HP procurve template specifically keeps the field name consistent within the same vendor.

In ntc_templates/templates/hp_procurve_show_lldp_info_local-device.textfsm, the Value declaration:

-Value CAPABILITIES_ENABLED (\S.*\S)
+Value CAPABILITIES (\S.*\S)

And the matching rule in the Start state:

-  ^\s*System\s+Capabilities\s+Enabled\s*:\s+${CAPABILITIES_ENABLED}\s*$$
+  ^\s*System\s+Capabilities\s+Enabled\s*:\s+${CAPABILITIES}\s*$$

And the fixture key. In tests/hp_procurve/show_lldp_info_local-device/show_lldp_info_local-device.yml:

-    capabilities_enabled: "bridge"
+    capabilities: "bridge"

Apply the same single-line key rename to tests/hp_procurve/show_lldp_info_local-device/show_lldp_info_local-device2.yml.

Thanks!

[julmanglano]

Thanks @matt852 — agreed on the alignment with the sibling _remote-device_detail template. Renamed CAPABILITIES_ENABLED → CAPABILITIES in the template (Value declaration + Start-state rule) and both fixture YAMLs. Both parser tests still pass, meta tests all green.

[matt852]

A few additional suggestions as I continue refining the AI agent reviewer:

Recommendation: Changes Suggested

Breaking Change: No

Two regex-coverage suggestions before merge, plus a couple of optional thoughts.

Unused ProCurve alternation branch in the System Description rule. Neither fixture emits a description starting with ProCurve (both are Aruba and HP), so the branch is not exercised.

Recommended fix: Tighten the regex to the two branches the fixtures cover. In ntc_templates/templates/hp_procurve_show_lldp_info_local-device.textfsm:

-  ^\s*System\s+Description\s*:\s+(?:ProCurve|HP|Aruba)\s+${MODEL}\s+${SYSTEM_DESCRIPTION}\s*$$
+  ^\s*System\s+Description\s*:\s+(?:HP|Aruba)\s+${MODEL}\s+${SYSTEM_DESCRIPTION}\s*$$

Or — if you'd rather keep the three-way alternation for defensive reasons — add a third .raw/.yml fixture pair from a real device that emits System Description : ProCurve <model> … so the branch is exercised.

Why

The project standard for permissive regex constructs (alternation branches, optional groups, fallback rules) is that test data must exercise every branch — otherwise tighten the regex. The fixtures cover `HP` and `Aruba` but not `ProCurve`.

---

Unused vendor-less System Description fallback rule. The fallback at line 17 catches descriptions that don't start with ProCurve|HP|Aruba, but neither fixture takes that path — both match the vendor-prefixed rule on line 16.

Recommended fix: Either drop the fallback:

-  ^\s*System\s+Description\s*:\s+${SYSTEM_DESCRIPTION}\s*$$

Or keep it as a defensive parse and add a .raw/.yml fixture pair whose System Description does not start with a recognized vendor token (e.g., a different firmware variant), so the rule is exercised.

Why

Same rule as above — every catch-all rule needs a test that hits it, or it should be removed. Prose justification in the PR body doesn't substitute for fixture coverage; the goal is that any future maintainer can confirm the rule's behavior by reading the fixtures.

---

Optional — MODEL could align with the data-model dictionary. The captured values (JL255A, J9774A) are HP part numbers/SKUs, which docs/dev/data_model.md lists under PID ("Part IDs (PIDs), Stock Keeping Units (SKUs), and in some cases Models or Model Numbers"). For cross-vendor consumers, PID is more portable than MODEL.

Recommended fix (optional): Rename MODEL → PID in the template Value + the Start-state rule, and regenerate both fixture YAMLs.

-Value MODEL (\S+)
+Value PID (\S+)

-  ^\s*System\s+Description\s*:\s+(?:ProCurve|HP|Aruba)\s+${MODEL}\s+${SYSTEM_DESCRIPTION}\s*$$
+  ^\s*System\s+Description\s*:\s+(?:ProCurve|HP|Aruba)\s+${PID}\s+${SYSTEM_DESCRIPTION}\s*$$

Apply the same model: → pid: key rename in both fixture YAMLs.

Why

`PID` is the canonical name in the data-model dictionary for SKU/part-number captures, and `MODEL` is not in the dictionary at all. Cross-vendor name normalization is the project's top standard.

---

Optional — LLDP Port Information rows. The PR description notes this section is intentionally not captured because it would duplicate show lldp info remote-device. Worth flagging that the local-device port table is structurally distinct (it's the local device's own port advertisements, not neighbors). If you'd like to keep it out of scope here, a one-line comment in the PortSection state noting the intent would help future readers; otherwise, decomposing it into LOCAL_INTERFACE / PORT_TYPE / LOCAL_PORT_ID / LOCAL_PORT_DESCRIPTION captures would be a clean follow-up.

Why

The data-model-coverage rule asks contributors to expose every meaningful field a downstream consumer might want — adding a capture later can be a breaking change.

Thanks!

[julmanglano]

Thanks @matt852 —

Probed 124 hp_procurve devices across the estate: 0 hits on the ProCurve-prefixed System Description and 0 hits on the vendor-less fallback. Dropped both branches.

Picked up the MODEL → PID rename in the same push — JL255A/J9774A are HP SKUs, and docs/dev/data_model.md lists those under PID. Matching model: → pid: rename in both yml fixtures.

Worth flagging: the parsed-output key rename has a downstream consumer in the nautobot-app-device-onboarding command mappers (hp_procurve.yml and aruba_os.yml both pull [*].model for device_type). Aligned them on my upstreaming branch in lockstep so the merge window stays honest.

On the LLDP Port Information decomposition — fair point that retrofitting it later would be breaking. Will queue as a follow-up so this PR stays scoped to the two required findings; happy to revisit if you'd prefer to bundle.

Parser tests + meta tests all green locally.

Pushed.

[julmanglano]

Thanks @matt852 — rebased on top of #2284 to combine both improvements.

Two additive changes layered onto #2284's :

1. CHASSIS_ID broadened from \S+ to \S.*\S. Production-validated on standalone HP 2530-8G (J9774A, YA.16.10) which outputs Chassis Id : aa bb cc dd ee ff (space-separated bytes). With the original regex the rule fails to
   match, the parse aborts on ^. -> Error, and device_type discovery breaks downstream. Added hp_procurve_show_lldp_info_local-device3.raw as a regression fixture covering this format.

2. PID added as a new Filldown Value, extracted from the System Description via a Continue rule. Keeps description semantics unchanged (whole string still captured)

Per-port captures (LOCAL_INTERFACE / PORT_TYPE / PORT_ID / PORT_DESCRIPTION) from #2284 preserved intact. Existing yml fixtures updated with the new pid key. Parser tests + meta tests all green locally.