[pastoreerrante]

ISSUE TYPE

• Bugfix Pull Request

COMPONENT

hp_procurve_show_system.textfsm — hp_procurve, show system

SUMMARY

Fixes #2370

Long System Contact / System Location lines wrap at column 78 onto indented continuation lines that can contain several words.

The existing rule ^\s+\S+$$ only matches continuation lines holding a single word (no spaces), so multi-word ones fell through to ^. -> Error and the whole parse fails.

Changes:

• Replace the ^\s+\S+$$ rule with ^\s+(?!.*\s:\s)\S.*$$. Every field line has a label : value separator (whitespace, colon, whitespace) and continuation lines do not, so the negative lookahead skips only wrapped text. A hardcoded indentation width (e.g. ^\s{23}) would have worked as well. It was considered but rejected as too fragile (due to the weird hardcoded integer).

  The new pattern works like this:

  ^      \s+      (?!.*\s:\s)      \S.*      $$
  │      │        │                │         │
  │      │        │                │         └─ end of line
  │      │        │                └─ first non-space character, then anything after it
  │      │        └─ negative lookahead check: there is NO "space colon space" anywhere further on the line
  │      └─ one or more leading spaces (the line must be indented)
  └─ start of line
  

• Accept Allow V2 Modules (seen on a real output) in addition to Allow V1 Modules.

• Added hp_procurve_show_system4 fixture (sanitized real output) covering both cases. Once parsed, the contact field keeps only the first line discarding the wrapped continuation text. This is consistent with the existing hp_procurve_show_system3 fixture.

Tested locally with invoke tests --local (black, flake8, pylint, yamllint, pydocstyle, bandit, pytest): all passed, 4857 tests.

Input (excerpt of the new hp_procurve_show_system4.raw fixture):

  System Contact     : Network Infrastructure Team (network-infrastructure@exa
                       mple.com) location Site-A Building-1 Floor-2 SW-ACCESS-
                       01
  System Location    : Site-A Building-1 Rack-12 SW-ACCESS-01

  Allow V2 Modules   : Yes

Before (current master): the whole parse fails.

textfsm.parser.TextFSMError: State Error raised. Rule Line: 47. Input Line:                        mple.com) location Site-A Building-1 Floor-2 SW-ACCESS-

After (this PR): parses fine. The two wrapped contact lines are skipped, so contact holds only the text from the System Contact line (same as the existing hp_procurve_show_system3 fixture).

- name: "SW-ACCESS-01"
  contact: "Network Infrastructure Team (network-infrastructure@exa"
  location: "Site-A Building-1 Rack-12 SW-ACCESS-01"
  allow_mods: "Yes"
  serial: "AB12CDE3FK"
  software_version: "KB.16.10.0020"

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[joewesch]

After (this PR): parses fine. The two wrapped contact lines are skipped, so contact holds only the text from the System Contact line (same as the existing hp_procurve_show_system3 fixture).

I would have considered this a bug, not something to replicate. Is there any way to parse the entire contact instead?

[pastoreerrante]

@joewesch fair point but, as far as I understood, TextFSM can't join text from different lines into one string value.

The only "trick" I could find for multi-line values is by using List + Continue (see NTC's parsing strategies post) but this is ideal when the value to be parsed is naturally a list, e.g. Cisco show vlan output:

  50   VLan50                           active    Fa0/1, Fa0/2, Fa0/3, Fa0/4, Fa0/5, Fa0/6, Fa0/7, Fa0/8, Fa0/9
                                                  Fa0/10, Fa0/11, Fa0/12

Applied to this scenario, contact would change from string to list. The result would be something like: ["Network Infrastructure Team (network-infrastructure@exa", "mple.com) location Site-A Building-1 Floor-2 SW-ACCESS-", "01"].

This introduces problems:

• it's a breaking change to an existing template's output: every consumer reading contact as a string would break, even though nautobot_device_onboarding/command_mappers/hp_procurve.yml does not read contact, so in theory nothing is going to break but there might be other users of ntc-templates...
• contact line is cut mid-word at column 78, so consumer would have to rebuild the value with "".join(...).
• I guess that If a cut ever falls on a space, the leading whitespace of the continuation line might be skipped, so the space would be likely lost.

That's why I'd prefer to keep this PR as the minimal fix for the parse failure in #2370 (no output type change).