feat: Cisco IOS-XR gNMI support via module-anchored SetRequest encoding

[steiler]

Adds first-class support for Cisco IOS-XR / XRd devices as gNMI targets by introducing a materialization layer that owns all NOS-specific encoding, keeping the gNMI transport driver a thin wire-execution layer.

Companion proto change: sdcio/sdc-protos#120 (adds device_profile field)

┌─────────────────────────────────────────────────────────────────────────┐
│  BEFORE                                                                 │
│                                                                         │
│  applyIntent                                                            │
│      │                                                                  │
│      ▼                                                                  │
│  TargetSource adapter  ◄── api.Entry wrapped here                       │
│      │                                                                  │
│      ▼                                                                  │
│  Target.Set(TargetSource)                                               │
│      │                                                                  │
│      ▼                                                                  │
│  gNMI driver  ── serializes internally ──► SetRequest                   │
│                                             └─ Update{origin:"", /}     │
│                                                  └─ entire JSON blob    │
│                                                                         │
│  (IOS-XR rejects: unknown native YANG keys in OpenConfig context)       │
└─────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────┐
│  AFTER                                                                  │
│                                                                         │
│  applyIntent                                                            │
│      │  api.Entry + replace flag                                        │
│      ▼                                                                  │
│  materialize.BuildPlan(entry, device-profile)                           │
│      │                                                                  │
│      ├─[generic / proto]──────────────► GnmiSetPlan (single update)     │
│      │                                                                  │
│      └─[cisco-ios-xr + json/json_ietf]                                  │
│              │                                                          │
│              ▼                                                          │
│         permodule encoder                                               │
│         group children by ModuleName                                    │
│              │                                                          │
│              ▼                                                          │
│         GnmiSetPlan                                                     │
│           ├─ Update{origin:"Cisco-IOS-XR-ip-static-cfg", /router}       │
│           ├─ Update{origin:"Cisco-IOS-XR-ifmgr-cfg",     /interfaces}   │
│           └─ ...one per module...                                       │
│                                                                         │
│      ▼                                                                  │
│  Target.Set(SouthboundSetPlan)   ◄── typed plan, no NOS logic here      │
│      │                                                                  │
│      ▼                                                                  │
│  gNMI driver (transport only) ──────► single SetRequest                 │
│                                        └─ all module Updates atomic     │
└─────────────────────────────────────────────────────────────────────────┘

Core additions:

• New pkg/datastore/target/materialize package: translates api.Entry + device-profile into a typed SouthboundSetPlan before any transport call
• New pkg/datastore/target/gnmi/permodule encoder: groups config tree children by YANG module name, emits one Update per module with Path.origin set to the full module name (e.g. Cisco-IOS-XR-ip-static-cfg) — all updates in a single SetRequest to preserve gNMI atomicity
• New pkg/datastore/target/types discriminated plan type (GnmiSetPlan / NetconfSetPlan) replacing the TargetSource abstraction on the Set path
• device-profile: cisco-ios-xr config field on SBI with closed-set validation: unknown profiles fail at load time; cisco-ios-xr + netconf is rejected; cisco-ios-xr + proto is accepted without IOS-XR shaping

Transport/driver changes:

• gNMI driver (gnmi.go) simplified to pure transport: receives a pre-built GnmiSetPlan and executes it, with no knowledge of device-profile or module grouping
• Replace transactions encoded as per-module delete + per-module update pairs in one SetRequest (gNMI replace field not used, consistent with existing behavior)
• Delete paths carry origin resolved from schema metadata or schema-client lookup for choice-case entries

Removals / cleanup:

• TargetSource interface and its adapters retired from the Set path (targetsource.go, target_source_replace.go, entryoutputadapter.go deleted)
• applyIntent now passes raw api.Entry + replace flag to materialize instead of wrapping in a TargetSource adapter

Test coverage added:

• permodule encoder: multi-module tree assertions (update count, origin values, path elements, JSON body shape, replace delete emission)
• materialize: BuildPlan assertions for both generic and IOS-XR profiles
• config: validation rejection of unknown profiles and netconf+ios-xr
• noop and gNMI get path: adapted to new plan-based interface

[codecov]

Codecov Report

❌ Patch coverage is 57.51880% with 113 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
pkg/datastore/target/materialize/materialize.go	45.78%	38 Missing and 7 partials ⚠️
pkg/datastore/target/gnmi/permodule/encode.go	77.98%	12 Missing and 12 partials ⚠️
pkg/server/datastore.go	0.00%	19 Missing ⚠️
pkg/datastore/target/netconf/nc.go	0.00%	9 Missing ⚠️
pkg/datastore/target/gnmi/gnmi.go	0.00%	6 Missing ⚠️
pkg/datastore/target/types/setplan.go	0.00%	4 Missing ⚠️
pkg/datastore/intent_rpc.go	60.00%	1 Missing and 1 partial ⚠️
pkg/datastore/target/noop/noop.go	90.90%	2 Missing ⚠️
pkg/datastore/sync.go	0.00%	1 Missing ⚠️
pkg/datastore/transaction_rpc.go	50.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[steiler]

@giacoliva if I provide proper instructions to you how to test this, whould you be able to do so?
Thanks already in advance.

[steiler]

@ipgst thank you for the extremely detailed writeup on #483 — that's exactly the kind of real-device evidence we didn't have when this PR was written. We went through the reproduction line by line against permodule's current implementation (the encoder this PR adds for device-profile: cisco-ios-xr) and found a likely root cause, plus a few things we still can't determine without your lab.

What we think is actually wrong

Cisco's own gNMI docs for native-YANG writes show origin as one of three fixed values (openconfig / cisco_native / cisco_cli), with the YANG module conveyed as a colon-prefix on the path element itself, e.g.:

path: { origin: "cisco_native" elem: { name: "Cisco-IOS-XR-shellutil-cfg:host-names" } elem: { name: "host-name" } }
val: { json_ietf_val: "\"abc\"" }

That's exactly the shape your working json_ietf_val reproduction used (module-prefixed element name, no/implicit origin). permodule.moduleRootPath in this PR does the opposite: it sets Path.Origin to the literal module name (e.g. "Cisco-IOS-XR-ip-static-cfg") and leaves the element name unprefixed — a convention that, as far as we can tell, only appears in Cisco's older Get/telemetry examples, never validated for Set. We think this is the primary defect, independent of anything else in the issue.

What we plan to change (pending your confirmation below)

1. Drop Path.Origin = <module name>; instead prefix the module name directly onto the first path element's name (matching your working reproduction), with origin left unset or set to cisco_native.
2. Keep the existing per-module batching (one Update per top-level module container, whole subtree as one JSON body) rather than moving to full per-leaf — less data on the wire — unless your test upgrade to new schemapb and add local schema store #1 below shows XRd rejects container-scoped bodies.
3. Reject device-profile: cisco-ios-xr + encoding: PROTO at config-load time (mirroring how sonic is restricted to JSON_IETF-only) — your test showed string_val fails even at correct leaf/path granularity, which points to native scalar TypedValues being fundamentally unsupported here, not just differently shaped.

Could you run a few more probes for us?

Same style as your original report — gnmic --dry-run output plus the live result for each, would be hugely helpful. All against the same MgmtEth0/RP0/CPU0/0 interface/description leaf unless noted.

1. Container-scoped body (validates whether per-module batching, not just per-leaf, survives on XRd):

gnmic -a 11.4.20.12:9339 --insecure -u clab -p 'clab@123' \
  set --update '/Cisco-IOS-XR-um-interface-cfg:interfaces/interface[interface-name=MgmtEth0/RP0/CPU0/0]:::json_ietf:::{"description":"XRd container-scope test"}'

2a. Explicit cisco_native origin (does it change anything vs. no origin at all?):

gnmic -a 11.4.20.12:9339 --insecure -u clab -p 'clab@123' \
  set --update 'cisco_native:/Cisco-IOS-XR-um-interface-cfg:interfaces/interface[interface-name=MgmtEth0/RP0/CPU0/0]/description:::json_ietf:::"XRd cisco_native origin test"'

2b. Origin = literal module name, unprefixed element (today's permodule shape — we expect this to fail; confirming):

gnmic -a 11.4.20.12:9339 --insecure -u clab -p 'clab@123' \
  set --update 'Cisco-IOS-XR-um-interface-cfg:/interfaces/interface[interface-name=MgmtEth0/RP0/CPU0/0]/description:::json_ietf:::"XRd module-as-origin test"'

3. Plain JSON (non-IETF) instead of JSON_IETF, same leaf:

gnmic -a 11.4.20.12:9339 --insecure -u clab -p 'clab@123' \
  set --update '/Cisco-IOS-XR-um-interface-cfg:interfaces/interface[interface-name=MgmtEth0/RP0/CPU0/0]/description:::json:::"XRd plain JSON test"'

4. Non-string leaf via PROTO (confirms scalar TypedValue is rejected in general, not just for strings) — substitute any integer/boolean leaf you have under the interface or ipv4 model, e.g. an MTU-style leaf:

gnmic -a 11.4.20.12:9339 --insecure -u clab -p 'clab@123' \
  set --update '/Cisco-IOS-XR-um-interface-cfg:interfaces/interface[interface-name=MgmtEth0/RP0/CPU0/0]/<some-int-or-bool-leaf>:::<uint/bool>:::<value>'

5. Multi-module single SetRequest (does XRd accept two different modules' updates atomically in one SetRequest, which is what our per-module encoder would send) — using a non-management interface to avoid any connectivity risk, set both description (interface-cfg module) and an IPv4 address (Cisco-IOS-XR-um-if-ipv4-cfg module, already in your schema) in a single gnmic set invocation with two --update flags.

6. Delete at module-root container path (untested so far) — a gnmic set --delete '/Cisco-IOS-XR-um-interface-cfg:interfaces/interface[interface-name=MgmtEth0/RP0/CPU0/0]' followed by re-adding it, just to see if a container-scoped delete behaves sanely or has unexpected blast radius.

No pressure to run all six if some are impractical in your lab — even a subset narrows this down a lot. We'll use whatever you can share to finalize the fix rather than guessing at the wire format again. Thanks again for such a thorough report!

[steiler]

@ipgst following up on our earlier comment — we ran your six probes (and a couple more) against a local containerlab Cisco XRd instance ourselves rather than waiting on lab access, since #1–#3 below directly settle the questions we'd asked you to confirm. Results, and the fix that landed as a result.

Lab used: clab-cisco-ixr01, image registry.srlinux.dev/pub/cisco_8201-32fh_214:7.10.1 (cisco_c8000 containerlab kind), gNMI on port 57400. Note the version gap up front: this is XR 7.10.1, you're on 26.2.1 — see the ask at the bottom.

Results (mapped to the probes we asked for)

#	Probe	Result
1	Container-scoped body (module-root, whole subtree as one json_ietf_val)	✅ Pass
2a	origin: cisco_native + module-prefixed path element	✅ Pass
2b	origin: <literal module name>, unprefixed element (today's permodule shape)	✅ Pass
3	Plain JSON (json_val, non-IETF), both per-leaf and module-root	❌ Fail — "not supported val type: 10"
4	PROTO scalars (string_val, uint_val), per-leaf	❌ Fail — "not supported val type: 1" / "3"
5	Multi-module single SetRequest (two modules, one RPC)	✅ Pass
6	Module-root delete	✅ Pass, clean, no side effects
—	Delete + update on the same module in one SetRequest (replace semantics)	✅ Pass

The important correction to our own hypothesis

In our last comment we suspected permodule.moduleRootPath's Path.Origin = <module name> (unprefixed element) convention — #2b above — was the actual defect, and planned to change it to match Cisco's documented cisco_native-origin / module-prefixed-element shape (#2a). That hypothesis was wrong: both #2a and #2b passed identically against XRd. permodule's existing encoding (the one this PR already ships) works correctly as-is — no defect found in it, its dispatch, or the underlying design. So we did not change permodule's wire format.

What we did confirm as genuinely broken, exactly matching what you found: plain JSON and PROTO scalar TypedValues are categorically rejected by XRd's native-YANG Set endpoint, independent of leaf/path granularity or origin annotation. XRd's Set accepts json_ietf_val only, full stop.

What shipped

• device-profile: cisco-ios-xr + encoding: PROTO or plain encoding: JSON is now rejected at config-load time with a clear error, instead of silently reaching the device and failing with a confusing "not supported val type: N" at reconcile time — b5bc3e9.
• materialize.BuildPlan's cisco-ios-xr dispatch is narrowed to JSON_IETF only (defensive — config validation is now the primary guard) — 3d94d84.
• New ADR recording the verification and the restriction decision, plus the original design ADR (never actually committed until now) it builds on: ADR 0001 (6e93048), ADR 0002 (0a3d1f5).

Net effect for you: set device-profile: cisco-ios-xr with encoding: JSON_IETF — that's the only combination that's valid and the only one that's been verified end-to-end.

One prerequisite you'll still need

Your TargetConnectionProfile in the issue doesn't reference device-profile at all — that field is exposed on the config-server side by sdcio/config-server#484, which is currently open and unmerged. You'll need that landed (or a build off that branch) before device-profile: cisco-ios-xr is actually settable via the CRD.

The ask

We tested on XR 7.10.1; you're on 26.2.1 — a substantially newer train. Our verification is strong evidence, not a substitute for your hardware. Once you have config-server with #484 and can pull an updated data-server build off this branch, could you retest end-to-end with device-profile: cisco-ios-xr + encoding: JSON_IETF against your own 26.2.1 XRd and let us know here whether it holds up? Thanks again for the original writeup — it's what made all of this findable.

[ipgst]

Hi, I’ve completed the end-to-end validation against XRd 26.2.1 and the new IOS-XR device profile works successfully.

Test environment

• XRd: 26.2.1
• config-server API/controller built from PR Possible fix(deps): 13 vulnerable dependencies in go.mod #484:
  4b1153d3bfdaa4854a7151a1d61d32cca80e9e12
• data-server:
  ghcr.io/sdcio/data-server:4298333

TargetConnectionProfile:

spec:
  port: 9339
  protocol: gnmi
  encoding: JSON_IETF
  deviceProfile: cisco-ios-xr
  insecure: true
  skipVerify: true

Test Config

spec:
  priority: 10
  revertive: true
  config:
  - path: /Cisco-IOS-XR-um-interface-cfg:interfaces/interface[interface-name=MgmtEth0/RP0/CPU0/0]/description
    value: SDCIO managed description

SDCIO reports the Config as Ready=True and the appliedConfig matches the requested value.

I also verified the value directly on XRd with gNMI:

gnmic -a 11.4.20.12:9339 \
  --insecure \
  -u clab \
  -p 'xxxxxxxxxx' \
  get \
  --path '/Cisco-IOS-XR-um-interface-cfg:interfaces/interface[interface-name=MgmtEth0/RP0/CPU0/0]/description' \
  --encoding json_ietf

Result:

interfaces/interface/description = "SDCIO managed description"

So I can confirm that:

deviceProfile: cisco-ios-xr
encoding: JSON_IETF

works end-to-end on XRd 26.2.1 as well.

This is especially useful because with the previous generic path on data-server v0.0.72, the same intent failed, while a direct gNMI json_ietf_val write succeeded.

Thanks for the implementation and for validating the behavior on XR 7.10.1. This confirms the same approach also works on the newer 26.2.1 train.

[steiler]

nice but there are issues I ran into still... interfaces worked fine for me as well.
however trying to use the full set of unified-model (um) schemas, I figured that e.g. al there router (bgp, static, ospf, ... ) are defined in their own yang module. with all of them defining "/router" so they can only be destinguished by their /<namespace/modulename>:router/... but this is not yet supported by schema server... so there is still work to be done.