carverauto/serviceradar

Fork 0

feat: WASM plugin for OpenText Network Automation integration #3325

New issue

Open

opened 2026-05-15 05:39:50 +00:00 by mfreeman451 · 5 comments

mfreeman451 commented

2026-05-15 05:39:50 +00:00

Owner

Is your feature request related to a problem?

Need to create a new (WASM) plugin for an OpenText (formerly HP Network Automation, and then MicroMuse Network Automation) Network Automation integration.

NA has a REST API that lets us get information from a device, device details, diagnostics, configurations and also allows us to run command scripts or diagnostics.

Typically command scripts and diagnostics are already built in NA and you just call them with the arguments you want, NA executes the command script (change plan) on a device and returns the results. Diagnostics are similar, I believe in the newer versions you can also pass inputs as variables to diagnostics. The main difference between the two is that diagnostics save output and you can write policy checks against them for compliance.

Our v1/first pass of this plugin needs to include:

retrieving configurations for a device
running a command script against a device
running a diagnostic against a device

When we're running a command script or a diagnostic, we need to setup a polling loop to check the status, retrieve results (output and success/failure), and store them in SR.

If we're retrieving a configuration for a device, we need to capture the config and store it in the database.

This is a tall order since normally you would want to parse the config, and kind of put it into a structured schema. This could be a huge effort, so we have a couple of options:

Throw the config in the database as a BLOB, use bm25/parade extension for text base searches for the stuff we care about
Write parsers for a limited set of device types (Cisco IOS, ArubaCX, HPE ProCurve)

Writing parsers for these 3 device types might not be that big of a deal, this is all we really need to support for this particular effort.

A 3rd option might be to do both, parse configs where we have parsers written, for everything else it gets stored as a blob and we could show the full config, wouldn't really be able to render it that well, but we could still be able to do BM25 text searches across it.

After digging into this a bit more, it seems like there is quite a lot of OSS config parsers we could borrow from that might be able to make this a bit easier.. the big challenge here is trying to come up with a schema that is generic enough that all of these different vendors/device types would fit into.

https://pypi.org/project/cisco-config-parser/
https://github.com/mpenning/ciscoconfparse2
https://www.pennington.net/py/ciscoconfparse2/
https://github.com/tdorssers/confparser
https://github.com/networktocode/netutils/blob/develop/netutils/config/parser.py
https://galaxy.ansible.com/ui/repo/published/community/network/content/module/aruba_config/ -- there are quite a few of other modules in here as well that we could examine
https://github.com/cidrblock/netcopa -- seems pretty decent

Almost all of these tools are written in python so I don't think we can use them directly, our backend is written in elixir, our agent is written in golang, and our WASM Plugin SDK supports go and rust.

I really don't want to pull in python/python dependencies either.

This feature should be broken up into the following feature parts:

NA API integration library in golang, handles authentication and API call abstractions
Config Schema that supports all vendors
Config Parsing engine that supports at least Cisco IOS, ArubaCX, and HPE ProCurve devices
ServiceRadar Config UI

The parsing engine should be easily extendable in the future to add support for new vendors/device types

At the end of the day, our main goal here is:

to be able to understand what configurations are applied to interfaces
understand if Global RADIUS is configured on a device

What we're trying to do is build in enough intelligence into SR and enough data into the database to use the ServiceRadar causal engine to help identify devices that may be having a problem because:

Network Access Controls are applied to a switchport
The endpoint/device is unreachable via ICMP or TCP scanning
We have potentially received errors from syslog related to the device (clearpass will be configured to send syslog messages to ServiceRadar)

These last parts we need to figure out later but this is the foundation that we need in place before we can add in that stuff, we'll probably need some kind of compliance engine against configurations next where we can write a policy that basically defines what "Network Access Controls applied to a switch port" looks like, since they're different for each device type.

For the OpenText Network Automation API integration, we need to kind of make this generic enough that we could easily swap this out with some other NCM tool integration, maybe ansible, or who knows, it shouldn't really matter.. we need to come up with high level abstractions that get these things we need from an NCM tool. Most NCM tools will provide the ability to:

collect configurations (NA returns the full, un-parsed or unnormalized config)
run a command on a device that makes a change
run a command (diagnostic) that collects output

We can just assume at least for now, that this will always be unstructured data.

Describe the solution you'd like

A clear and concise description of what you want to happen.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

**Is your feature request related to a problem?** Need to create a new (WASM) plugin for an OpenText (formerly HP Network Automation, and then MicroMuse Network Automation) Network Automation integration. NA has a REST API that lets us get information from a device, device details, diagnostics, configurations and also allows us to run command scripts or diagnostics. Typically command scripts and diagnostics are already built in NA and you just call them with the arguments you want, NA executes the command script (change plan) on a device and returns the results. Diagnostics are similar, I believe in the newer versions you can also pass inputs as variables to diagnostics. The main difference between the two is that diagnostics save output and you can write policy checks against them for compliance. Our v1/first pass of this plugin needs to include: - retrieving configurations for a device - running a command script against a device - running a diagnostic against a device When we're running a command script or a diagnostic, we need to setup a polling loop to check the status, retrieve results (output and success/failure), and store them in SR. If we're retrieving a configuration for a device, we need to capture the config and store it in the database. This is a tall order since normally you would want to parse the config, and kind of put it into a structured schema. This could be a huge effort, so we have a couple of options: - Throw the config in the database as a BLOB, use bm25/parade extension for text base searches for the stuff we care about - Write parsers for a limited set of device types (Cisco IOS, ArubaCX, HPE ProCurve) Writing parsers for these 3 device types might not be that big of a deal, this is all we really need to support for this particular effort. A 3rd option might be to do both, parse configs where we have parsers written, for everything else it gets stored as a blob and we could show the full config, wouldn't really be able to render it that well, but we could still be able to do BM25 text searches across it. After digging into this a bit more, it seems like there is quite a lot of OSS config parsers we could borrow from that might be able to make this a bit easier.. the big challenge here is trying to come up with a schema that is generic enough that all of these different vendors/device types would fit into. https://pypi.org/project/cisco-config-parser/ https://github.com/mpenning/ciscoconfparse2 https://www.pennington.net/py/ciscoconfparse2/ https://github.com/tdorssers/confparser https://github.com/networktocode/netutils/blob/develop/netutils/config/parser.py https://galaxy.ansible.com/ui/repo/published/community/network/content/module/aruba_config/ -- there are quite a few of other modules in here as well that we could examine https://github.com/cidrblock/netcopa -- seems pretty decent Almost all of these tools are written in python so I don't think we can use them directly, our backend is written in elixir, our agent is written in golang, and our WASM Plugin SDK supports go and rust. I really don't want to pull in python/python dependencies either. This feature should be broken up into the following feature parts: - [ ] NA API integration library in golang, handles authentication and API call abstractions - [ ] Config Schema that supports all vendors - [ ] Config Parsing engine that supports at least Cisco IOS, ArubaCX, and HPE ProCurve devices - [ ] ServiceRadar Config UI The parsing engine should be easily extendable in the future to add support for new vendors/device types At the end of the day, our main goal here is: - [ ] to be able to understand what configurations are applied to interfaces - [ ] understand if Global RADIUS is configured on a device What we're trying to do is build in enough intelligence into SR and enough data into the database to use the ServiceRadar causal engine to help identify devices that may be having a problem because: - Network Access Controls are applied to a switchport - The endpoint/device is unreachable via ICMP or TCP scanning - We have potentially received errors from syslog related to the device (clearpass will be configured to send syslog messages to ServiceRadar) These last parts we need to figure out later but this is the foundation that we need in place before we can add in that stuff, we'll probably need some kind of compliance engine against configurations next where we can write a policy that basically defines what "Network Access Controls applied to a switch port" looks like, since they're different for each device type. For the OpenText Network Automation API integration, we need to kind of make this generic enough that we could easily swap this out with some other NCM tool integration, maybe ansible, or who knows, it shouldn't really matter.. we need to come up with high level abstractions that get these things we need from an NCM tool. Most NCM tools will provide the ability to: - collect configurations (NA returns the full, un-parsed or unnormalized config) - run a command on a device that makes a change - run a command (diagnostic) that collects output We can just assume at least for now, that this will always be unstructured data. **Describe the solution you'd like** A clear and concise description of what you want to happen. **Describe alternatives you've considered** A clear and concise description of any alternative solutions or features you've considered. **Additional context** Add any other context or screenshots about the feature request here.

mfreeman451 commented

2026-05-15 05:55:30 +00:00

Author

Owner

This PRD outlines the development of a Network Configuration & Automation Integration for ServiceRadar, specifically targeting OpenText Network Automation (NA). This integration will leverage the ServiceRadar WASM-based architecture to collect, parse, and analyze network configurations to feed into the ServiceRadar causal engine.

PRD: ServiceRadar Network Automation Integration (OpenText NA)

Status: Draft
Author: ServiceRadar Engineering
Date: May 2024
Target Architecture: WASM (wazero), OCSF, Go/Elixir Pipeline

1. Problem Statement

ServiceRadar currently lacks deep visibility into the configuration state of network infrastructure. When an endpoint becomes unreachable or experiences issues, it is difficult to programmatically determine if the cause is a configuration change (e.g., Network Access Control/NAC applied to a switch port) or a global configuration error (e.g., RADIUS misconfiguration).

Manual retrieval of configs from OpenText NA is slow and siloed. We need an automated way to pull, parse, and store these configurations in a structured format while maintaining the ability to execute diagnostic scripts and command changes directly from ServiceRadar.

2. Goals & Objectives

Automated Collection: Periodically retrieve configurations, run diagnostics, and execute command scripts via OpenText NA REST APIs.
Structured Visibility: Parse raw configurations into a vendor-agnostic schema for Cisco IOS, ArubaCX, and HPE ProCurve.
Searchability: Provide full-text search (BM25) over all configurations, including those without specific parsers.
Causal Foundation: Provide the data necessary to correlate network reachability issues with configuration states (Interface NAC, RADIUS settings).
Extensibility: Build a generic "NCM (Network Configuration Manager) Abstraction" so NA can be replaced or supplemented by Ansible/NetBox in the future.

3. Technical Architecture

3.1 Data Flow

ServiceRadar Agent: Runs a WASM plugin (via wazero) written in Go.
Plugin: Authenticates with OpenText NA, triggers jobs, and polls for completion.
Exfiltration: Data is packaged into OCSF-compliant schemas and sent:
Agent -> Agent-Gateway -> Core-ELX (Elixir) -> Database (Postgres/ParadeDB).
Storage:
- Structured: Parsed JSON fields for interfaces/global settings.
- Unstructured: Raw config stored as a BLOB with BM25/ParadeDB indexing for full-text search.

3.2 Integration Components

NA API Go Library: A standalone Go module for the WASM plugin to interact with the NA REST API (Authentication, Change Plans, Diagnostics, Config Retrieval).
Config Parsing Engine: A regex/grammar-based parser (Go) capable of normalizing Cisco/Aruba/HPE CLI into JSON.
Polling Manager: Logic within the plugin to handle the asynchronous nature of NA jobs (request job -> poll status -> fetch results).

4. Functional Requirements

4.1 Configuration Retrieval (v1)

The plugin must pull the "Running Config" for targeted devices.
If a parser exists for the device type, extract:
- Interfaces: Name, Description, Status, VLAN, NAC/802.1x settings, Port-Security.
- Global Settings: RADIUS/TACACS server IPs, Timeout settings, Global AAA status.
Store the raw config regardless of parsing success.

4.2 Command & Diagnostic Execution

Command Scripts (Change Plans): Trigger an existing NA Change Plan with arguments.
Diagnostics: Trigger an NA Diagnostic.
Polling Loop:
- Implement a back-off polling strategy to check Job Status.
- Capture stdout, stderr, and exit codes.
- Map output to ServiceRadar diagnostic logs.

4.3 Supported Vendors (v1 Parsing)

Cisco IOS
ArubaCX
HPE ProCurve

5. Data & Schema Definitions

5.1 OCSF Mapping

We will utilize the OCSF Inventory or Config State categories. Since OCSF is extensible, we will define a Network Configuration Profile:

device_hw: Metadata about the switch/router.
config_raw: The BLOB of the full config.
interfaces[]: An array of objects containing normalized port data.
aaa_config: Global RADIUS/Security settings.

5.2 Storage Strategy

Data Type	Storage Method	Purpose
Structured JSON	Postgres JSONB	Causal Engine analysis, UI tables, filtering.
Raw Config	Postgres BLOB (BM25 Indexed)	Full-text search (e.g., searching for a specific IP or string across all devices).

6. Parsing Strategy (The "Go" Way)

Since we cannot use Python libraries (ciscoconfparse), we will implement a lightweight Pattern-Match Parser in Go:

Use a Scanner approach to read configs line-by-line.
Define a set of InterfaceBlock extractors for each vendor.
Fallback: If a device type is unknown, the system defaults to "Raw Only" storage.

7. UI/UX Requirements

Device Config View: A tab in the ServiceRadar Device Detail view showing the current configuration.
Search: A global search bar to perform BM25 queries across all stored network configs.
Job Runner: A UI component to select a "Diagnostic" or "Command Script" from NA, input variables, and view a real-time polling status bar with the final output.
Diff View: (Future) Ability to compare the current config with a previous version.

8. Future Evolution: The Causal Engine

This integration provides the "Evidence" for the ServiceRadar Causal Engine:

Symptom: Endpoint 10.0.0.5 is unreachable (ICMP Fail).
Event: Syslog from ClearPass shows a RADIUS Reject.
Root Cause Analysis: ServiceRadar checks the parsed Config for the switchport where 10.0.0.5 sits. It sees dot1x port-control auto is enabled but the Global RADIUS server is misconfigured or unreachable.
Result: ServiceRadar flags a "Network Access Control Configuration Conflict."

9. Success Metrics

Coverage: 100% of Cisco, Aruba, and HPE devices in the environment have their latest config stored in SR.
Performance: WASM plugin executes and returns a 2MB config file in under 5 seconds (excluding NA processing time).
Utility: Ability to successfully find a specific VLAN ID across the entire network using the BM25 search within the SR UI.

This PRD outlines the development of a **Network Configuration & Automation Integration** for ServiceRadar, specifically targeting **OpenText Network Automation (NA)**. This integration will leverage the ServiceRadar WASM-based architecture to collect, parse, and analyze network configurations to feed into the ServiceRadar causal engine. --- # PRD: ServiceRadar Network Automation Integration (OpenText NA) **Status:** Draft **Author:** ServiceRadar Engineering **Date:** May 2024 **Target Architecture:** WASM (wazero), OCSF, Go/Elixir Pipeline --- ## 1. Problem Statement ServiceRadar currently lacks deep visibility into the configuration state of network infrastructure. When an endpoint becomes unreachable or experiences issues, it is difficult to programmatically determine if the cause is a configuration change (e.g., Network Access Control/NAC applied to a switch port) or a global configuration error (e.g., RADIUS misconfiguration). Manual retrieval of configs from OpenText NA is slow and siloed. We need an automated way to pull, parse, and store these configurations in a structured format while maintaining the ability to execute diagnostic scripts and command changes directly from ServiceRadar. ## 2. Goals & Objectives * **Automated Collection:** Periodically retrieve configurations, run diagnostics, and execute command scripts via OpenText NA REST APIs. * **Structured Visibility:** Parse raw configurations into a vendor-agnostic schema for Cisco IOS, ArubaCX, and HPE ProCurve. * **Searchability:** Provide full-text search (BM25) over all configurations, including those without specific parsers. * **Causal Foundation:** Provide the data necessary to correlate network reachability issues with configuration states (Interface NAC, RADIUS settings). * **Extensibility:** Build a generic "NCM (Network Configuration Manager) Abstraction" so NA can be replaced or supplemented by Ansible/NetBox in the future. ## 3. Technical Architecture ### 3.1 Data Flow 1. **ServiceRadar Agent:** Runs a WASM plugin (via `wazero`) written in Go. 2. **Plugin:** Authenticates with OpenText NA, triggers jobs, and polls for completion. 3. **Exfiltration:** Data is packaged into **OCSF-compliant schemas** and sent: `Agent -> Agent-Gateway -> Core-ELX (Elixir) -> Database (Postgres/ParadeDB)`. 4. **Storage:** * **Structured:** Parsed JSON fields for interfaces/global settings. * **Unstructured:** Raw config stored as a BLOB with **BM25/ParadeDB** indexing for full-text search. ### 3.2 Integration Components * **NA API Go Library:** A standalone Go module for the WASM plugin to interact with the NA REST API (Authentication, Change Plans, Diagnostics, Config Retrieval). * **Config Parsing Engine:** A regex/grammar-based parser (Go) capable of normalizing Cisco/Aruba/HPE CLI into JSON. * **Polling Manager:** Logic within the plugin to handle the asynchronous nature of NA jobs (request job -> poll status -> fetch results). --- ## 4. Functional Requirements ### 4.1 Configuration Retrieval (v1) * The plugin must pull the "Running Config" for targeted devices. * If a parser exists for the device type, extract: * **Interfaces:** Name, Description, Status, VLAN, NAC/802.1x settings, Port-Security. * **Global Settings:** RADIUS/TACACS server IPs, Timeout settings, Global AAA status. * Store the raw config regardless of parsing success. ### 4.2 Command & Diagnostic Execution * **Command Scripts (Change Plans):** Trigger an existing NA Change Plan with arguments. * **Diagnostics:** Trigger an NA Diagnostic. * **Polling Loop:** * Implement a back-off polling strategy to check Job Status. * Capture `stdout`, `stderr`, and exit codes. * Map output to ServiceRadar diagnostic logs. ### 4.3 Supported Vendors (v1 Parsing) 1. **Cisco IOS** 2. **ArubaCX** 3. **HPE ProCurve** --- ## 5. Data & Schema Definitions ### 5.1 OCSF Mapping We will utilize the OCSF **Inventory** or **Config State** categories. Since OCSF is extensible, we will define a **Network Configuration Profile**: * `device_hw`: Metadata about the switch/router. * `config_raw`: The BLOB of the full config. * `interfaces[]`: An array of objects containing normalized port data. * `aaa_config`: Global RADIUS/Security settings. ### 5.2 Storage Strategy | Data Type | Storage Method | Purpose | | :--- | :--- | :--- | | **Structured JSON** | Postgres JSONB | Causal Engine analysis, UI tables, filtering. | | **Raw Config** | Postgres BLOB (BM25 Indexed) | Full-text search (e.g., searching for a specific IP or string across all devices). | --- ## 6. Parsing Strategy (The "Go" Way) Since we cannot use Python libraries (`ciscoconfparse`), we will implement a lightweight **Pattern-Match Parser** in Go: * Use a `Scanner` approach to read configs line-by-line. * Define a set of `InterfaceBlock` extractors for each vendor. * **Fallback:** If a device type is unknown, the system defaults to "Raw Only" storage. --- ## 7. UI/UX Requirements * **Device Config View:** A tab in the ServiceRadar Device Detail view showing the current configuration. * **Search:** A global search bar to perform BM25 queries across all stored network configs. * **Job Runner:** A UI component to select a "Diagnostic" or "Command Script" from NA, input variables, and view a real-time polling status bar with the final output. * **Diff View:** (Future) Ability to compare the current config with a previous version. --- ## 8. Future Evolution: The Causal Engine This integration provides the "Evidence" for the ServiceRadar Causal Engine: * **Symptom:** Endpoint `10.0.0.5` is unreachable (ICMP Fail). * **Event:** Syslog from ClearPass shows a RADIUS Reject. * **Root Cause Analysis:** ServiceRadar checks the parsed Config for the switchport where `10.0.0.5` sits. It sees `dot1x port-control auto` is enabled but the Global RADIUS server is misconfigured or unreachable. * **Result:** ServiceRadar flags a "Network Access Control Configuration Conflict." --- ## 9. Success Metrics * **Coverage:** 100% of Cisco, Aruba, and HPE devices in the environment have their latest config stored in SR. * **Performance:** WASM plugin executes and returns a 2MB config file in under 5 seconds (excluding NA processing time). * **Utility:** Ability to successfully find a specific VLAN ID across the entire network using the BM25 search within the SR UI.

mfreeman451 commented

2026-05-15 05:56:23 +00:00

Author

Owner

We will likely need to extend the agent/protobuf definitions to support the device configuration shape

mfreeman451 commented

2026-05-15 05:57:26 +00:00

Author

Owner

Future Considerations
Compliance Engine: Post-MVP, develop a policy engine to run "Audit" checks against the parsed data (e.g., "Alert if RADIUS is missing on any active switchport").
Configuration Diffing: Ability to compare two points in time to see exactly what changed in the raw text.
Causal Engine Hooks: Feeding the "NAC enabled" state as a node into the SR causal graph to automatically suppress/re-categorize reachability alerts.
Implementation Notes (Constraints)
No Python: All parsing logic must be written in Go (compiled to WASM) or handled in Elixir.
WASM Memory: Configurations can be large (1MB+ for some core switches). The WASM plugin must handle memory allocation efficiently within the wazero environment.
Vendor Generic: Avoid hardcoding OpenText specific logic outside of the na-provider module.

7. Future Considerations Compliance Engine: Post-MVP, develop a policy engine to run "Audit" checks against the parsed data (e.g., "Alert if RADIUS is missing on any active switchport"). Configuration Diffing: Ability to compare two points in time to see exactly what changed in the raw text. Causal Engine Hooks: Feeding the "NAC enabled" state as a node into the SR causal graph to automatically suppress/re-categorize reachability alerts. 8. Implementation Notes (Constraints) No Python: All parsing logic must be written in Go (compiled to WASM) or handled in Elixir. WASM Memory: Configurations can be large (1MB+ for some core switches). The WASM plugin must handle memory allocation efficiently within the wazero environment. Vendor Generic: Avoid hardcoding OpenText specific logic outside of the na-provider module.

mfreeman451 commented

2026-05-15 06:00:04 +00:00

Author

Owner

Found some golang based parsers:

https://github.com/tinyinput/confparser

Found some golang based parsers: https://github.com/tinyinput/confparser

mfreeman451 commented

2026-05-15 06:01:30 +00:00

Author

Owner

I like the netcopa approach of writing yaml here for each section of the config:

https://github.com/cidrblock/netcopa/blob/master/parsers/cisco_ios/interface/main.yml

We could build a totally separate UI just for building out these yaml configs (future work), but worth considering.. something that would allow us to paste in a real config and then build yaml and test it out in real-time.

Maybe build this in rust using iced.rs

I like the netcopa approach of writing yaml here for each section of the config: https://github.com/cidrblock/netcopa/blob/master/parsers/cisco_ios/interface/main.yml We could build a totally separate UI just for building out these yaml configs (future work), but worth considering.. something that would allow us to paste in a real config and then build yaml and test it out in real-time. Maybe build this in rust using iced.rs