hp_procurve_show_system: support VSF-stack standalone-line Serial Number

[julmanglano]

ISSUE TYPE

• Bugfix Pull Request

COMPONENT

hp_procurve, show system

SUMMARY

The current template captures Serial Number only when it appears on the
same line as ROM Version:

^\s*ROM Version\s+:\s+${ROM_VERSION}\s+Serial Number\s+:\s+${SERIAL}

That holds for standalone HP ProCurve switches, but VSF-stack output
splits each member's metadata across separate lines:

VSF-Member :1
  ROM Version        : WC.16.01.0008
  Up Time            : 458 days
  CPU Util (%)       : 5
  MAC Addr           : 548028-aabbd1
  Serial Number      : SN0000003A
  Memory   - Total   : 338,285,056

Result: on a stacked switch, serial parses as the first-member's serial
only (or empty, depending on stack config), and the per-member serials
are silently dropped.

This PR adds an additional rule that captures Serial Number on its own
line, falling through the existing combined rule when present:

^\s+Serial Number\s+:\s+${SERIAL}

SERIAL is a single-value (not List), so on stacks the captured value is
the last member's serial — mirroring the device's own behavior of only
exposing one serial in show system for stacked output. No schema
change; existing fixtures unaffected.

The new hp_procurve_show_system2.{raw,yml} fixture covers a 3-member
VSF stack and exercises the new fallback rule.

[mjbear]

Possible duplicate or overlap with PR #2283

I'd like to merge the above mentioned PR, then rebase this PR against the current state.

[mjbear]

@julmanglano
(Hopefully I didn't mess anything up for you with the rebase. 😮‍💨)

• I pulled your branch down, rebased it against our upstream state.
• Retained the existing second file of data (ends in number 2)
• Moved your new test data to a third file (ends in 3)
• The rebase required a force push because the commit hashes were different
• 📝 Note: Based on PR Add hp_procurve sh sys VSF stack support #2283, serial numbers are captured for each stack member

🎯 Please verify and test against a live device. Thank you!

[julmanglano]

Thanks @mjbear

Pulled the rebase and tested against my live 2-member VSF stack — the parse fails on real device output. System Contact wraps at column ~80 on HP procurve, and the orphan continuation hits ^. -> Error in the Start state, so the template is unusable against this device family as-is.

Anonymised example of the failing input:

  System Contact     : Network Operations Center (network-operations@example-long-domain.co
                       m)

A one-line swallow rule before ^. -> Error resolves it:

  ^\s{15,}\S

Verified locally — with the rule, the parse produces 2 records (one per VSF member), chassis-level Filldown values populate correctly across both, and per-member fields are distinct. Trade-off: contact (and location if it wraps too) is truncated to the first line.

Happy to push the fix to the branch — or you can apply it directly, whichever you prefer.

(The three committed fixtures still pass.)

[mjbear]

System Contact wraps at column ~80 on HP procurve, and the orphan continuation hits ^. -> Error in the Start state, so the template is unusable against this device family as-is.

Oh darn

Anonymised example of the failing input:

  System Contact     : Network Operations Center (network-operations@example-long-domain.co
                       m)

Thank you for the visual example.

A one-line swallow rule before ^. -> Error resolves it:

  ^\s{15,}\S

It's fifteen spaces today, but that could change -- it may be worth using a leading \s+
Next, it appears there's not "trailing" white space after the wrapped system contact data.

Maybe change the data regex to a repeating pattern and anchor on the end of the line?
(and add a comment to remind us far into the future)

-  ^\s{15,}\S
+# match long sys contact that wraps to next line
+  ^\s+\S+$$

[julmanglano]

Agree, again, like I said before. I can push the fix to the branch, or feel free to apply it yourself — whichever works best for you.

[mjbear]

@julmanglano
In your anonymized example, the line goes out to character 91.
Even though we'll anonymize, I would like the test data to be close to the real thing -- so what's the line length it wraps at?

[julmanglano]

Thanks @mjbear —

Wrap is at column 78 (2-char indent + 76 visible — standard 80-col terminal).

Tested a third stack while building the fixture and hit a case ^\s+\S+$$ doesn't catch. Anonymised, structure matches the real device:

example-switch# show system
...
  System Contact     : Network Operations Center (network-operations@example.c
                       om) location Building-3 Datacenter-Aisle-12 Rack-04 ABC
                       -ACCS1

Middle line has multiple tokens, so \S+$$ (one token to EOL) doesn't match. Relaxed to:

+# swallow wrap-continuation lines (long contact/location wrap at col 78)
+  ^\s+\S.*$$

Covers all three shapes I've seen — 1-, 2-, and 3-line wraps, single- or multi-token continuations. Specific field rules earlier in Start still take precedence so the swallow only fires on actual orphans.

Updated hp_procurve_show_system3 to cover the 3-line case. Captured value truncated to line 1, same trade-off as before.

Pushed.