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.

[mjbear]

Hmm, putting the location in the contact field (which is in the location field) is redundant. In my eyes these are self-induced problems.

From the test data, I see why you have this regex. The trade-off and risk is that this will match most lines. ⚠️

@julmanglano Is there a legitimate reason why the location is also in the System Contact?

I'll ping other maintainers for some feedback.

One item that comes to my mind is to state transition for System Contact and cover it and System Location with this loose regex. Once those two are handled in that new state, then state transition back to Start state. This way we should reduce the risk of over-matching lines because of this Contact/Location stuff.

[julmanglano]

Thanks @mjbear —

Agreed — checked more switches in the same network and the typical Contact is just Network Operations Center (network-operations@example.com), wrapping cleanly at col 78 with a single-token continuation. The location ... tail in the earlier example was an outlier, not how the rest of the network reports.

Going back to your ^\s+\S+$$ form and updating hp_procurve_show_system3 to a clean wrap. The longer multi-line shape will fail loudly on ^. -> Error, which feels right — not really worth bending the parser for a one-off.

Pushed.

[mjbear]

Agreed — checked more switches in the same network and the typical Contact is just Network Operations Center (network-operations@example.com), wrapping cleanly at col 78 with a single-token continuation.

We could capture those trailing sys contact characters if they're useful. We can't concatenate with TextFSM, but that can be in post-parsing.

I'm kicking around the sys contact and sys location parsing. Though maybe not for this PR since changing the data type to a List would be a "breaking change". (Then the thought is it worth capturing? 😅)

The location ... tail in the earlier example was an outlier, not how the rest of the network reports.

Going back to your ^\s+\S+$$ form and updating hp_procurve_show_system3 to a clean wrap. The longer multi-line shape will fail loudly on ^. -> Error, which feels right — not really worth bending the parser for a one-off.

Sounds good.

[julmanglano]

Thanks @mjbear — yes, the list + post-parse approach would be the proper way to capture the full wrapped value, agreed. But given that what we've seen so far looks more like a one-off admin practice on a single device rather than something device-wide, I'd say it's probably not worth changing the data type right now. Happy to revisit if more wrapped cases come up in real outputs.

[matt852]

One suggestion when working with an AI PR reviewer agent for handling contact and location that might work here in case either of them are empty:

• CONTACT/LOCATION empty-match branch needs fixture coverage (or revert the widening). Loosening these from (.+) to (.*) and the rule separator from \s+ to \s* introduces a new "empty Contact / empty Location" branch, but all three .raw fixtures populate both fields — the new branch isn't exercised. A show system from a switch with no Contact set is realistic device output worth capturing as a fixture; alternatively the minimal revert below restores the stricter pattern (I ran the scoped pytest against this revert and all 6 cases still pass).

  In ntc_templates/templates/hp_procurve_show_system.textfsm, the two Value declarations:

  -Value Filldown CONTACT (.*)
  -Value Filldown LOCATION (.*)
  +Value Filldown CONTACT (.+)
  +Value Filldown LOCATION (.+)

  And the two matching rules in Start:

  -  ^\s*System\s+Contact\s+:\s*${CONTACT}
  -  ^\s*System\s+Location\s+:\s*${LOCATION}
  +  ^\s*System\s+Contact\s+:\s+${CONTACT}
  +  ^\s*System\s+Location\s+:\s+${LOCATION}

[mjbear]

• In ntc_templates/templates/hp_procurve_show_system.textfsm, the two Value declarations:
  diff -Value Filldown CONTACT (.*) -Value Filldown LOCATION (.*) +Value Filldown CONTACT (.+) +Value Filldown LOCATION (.+)

Agreed. There's no test data with empty Contact or Location so there doesn't appear to be a reason to change the regex.