add parameter in the connection profile to set a specific target name

[henderiw]

Add a parameter in the connection profile to set a specific target name

[henderiw]

add a parameter in the TargetConnectionProfileSpec to indicate the targetName.

// TargetConnectionProfileSpec defines the desired state of TargetConnectionProfile
type TargetConnectionProfileSpec struct {
...
// +kubebuilder:validation:XValidation:rule="self == oldSelf",message="includeNS is immutable"
// +kubebuilder:default:=false
TargetName *bool json:"targetName,omitempty" yaml:"targetName,omitempty" protobuf:"varint,9,opt,name= targetName"
}

update sdc-proto
update data-server to convey it to the device

[reinaldosaraiva]

Thanks for consolidating the discussion here @henderiw!

I'd like to share our real-world use case and testing results to help refine the implementation approach.

Our Use Case: Dell SONiC EVPN-VXLAN Lab with SDC

We're building a GitOps-based network automation platform using SDC to manage Dell SONiC 4.4.1 switches. Our lab consists of 4 SONiC switches in an EVPN-VXLAN topology:

Lab Topology

┌──────────────────────────────────────────────────────────────────┐
│                    SDC/Kubenet (KinD)                            │
│           Schema Server + Config Server + Data Server            │
└────────────────────────────┬─────────────────────────────────────┘
                             │ gNMI (port 8080)
                             │
    ┌────────────────────────┼────────────────────────┐
    │                        │                        │
┌───▼───────┐          ┌─────▼─────┐          ┌──────▼──────┐
│mgc-spine-1│◄════════►│mgc-spine-2│          │  mgc-cg-1   │
│172.60.60.11│  iBGP RR │172.60.60.12│          │  (FRR)     │
│  AS 65100 │          │  AS 65100 │          └─────────────┘
└─────┬─────┘          └─────┬─────┘
      │\                    /│
      │ \    eBGP         / │
      │  \              /   │
┌─────▼─────┐      ┌───▼───────┐
│mgc-leaf-1 │      │mgc-leaf-2 │
│172.60.60.21│      │172.60.60.22│
│  AS 65201 │      │  AS 65202 │
└───────────┘      └───────────┘

Current SDC Configuration Files

TargetConnectionProfile (sonic-connection-profile.yaml):

apiVersion: inv.sdcio.dev/v1alpha1
kind: TargetConnectionProfile
metadata:
  name: gnmi-sonic
  namespace: sdc
spec:
  protocol: gnmi
  port: 8080
  encoding: JSON_IETF
  insecure: false
  skipVerify: true
  connectRetry: 30s
  timeout: 30s
  includeNS: true
  # MISSING: gnmiTarget field for SONiC compatibility

DiscoveryRule (mgc-sonic-discovery.yaml):

apiVersion: inv.sdcio.dev/v1alpha1
kind: DiscoveryRule
metadata:
  name: mgc-sonic-discovery
  namespace: sdc
spec:
  addresses:
    - address: 172.60.60.11
      hostName: mgc-spine-1
    - address: 172.60.60.12
      hostName: mgc-spine-2
    - address: 172.60.60.21
      hostName: mgc-leaf-1
    - address: 172.60.60.22
      hostName: mgc-leaf-2
  defaultSchema:
    provider: sonic.dell.sdcio.dev
    version: "4.4.1"
  targetConnectionProfiles:
    - connectionProfile: gnmi-sonic
      credentials: sonic-credentials
      syncProfile: sonic-sync

SONiC Switch Config (spine-1.cfg - excerpt):

{
  "DEVICE_METADATA": {
    "localhost": {
      "hostname": "mgc-spine-1",
      "hwsku": "Force10-S6000",
      "platform": "x86_64-kvm_x86_64-r0",
      "type": "SpineRouter"
    }
  },
  "GNMI": {
    "gnmi": {
      "port": "8080",
      "log_level": "2",
      "client_auth": "none"
    }
  },
  "FEATURE": {
    "gnmi": { "state": "enabled" },
    "bgp": { "state": "enabled" }
  }
}

The Problem

GET operations work perfectly - SDC discovers all 4 targets and they show as READY.

SET operations fail with:

status:
  conditions:
  - reason: Unrecoverable
    message: "runtime error: index out of range [-1]"

Root Cause Analysis

SONiC's gNMI implementation requires the target field in the Path prefix to specify which YANG model namespace to use:

Target Value	YANG Models	Description
OC-YANG	OpenConfig	Standard models (openconfig-interfaces, openconfig-system, etc.)
SONIC-YANG	Native SONiC	SONiC-specific models
(empty)	Rejected	SONiC doesn't know which namespace to use

Validated Test Results

# FAILS (no target):
$ gnmi_set -insecure -username admin -password admin \
    -target_addr 172.60.60.11:8080 \
    -update /openconfig-system:system/config:@./hostname.json

Error: unexpected field hostname

# WORKS (with OC-YANG target):
$ gnmi_set -insecure -username admin -password admin \
    -target_addr 172.60.60.11:8080 \
    -xpath_target OC-YANG \
    -update /openconfig-system:system/config:@./hostname.json

op: UPDATE
path: openconfig-system:system/config
# SUCCESS: hostname changed from "sonic" to "mgc-spine-1"

Why Boolean Won't Work for SONiC

I see the proposal is for a targetName boolean field:

TargetName *bool `json:"targetName,omitempty"`

If I understand correctly, when true, this would use the Target CR name as the gNMI target value.

The problem for SONiC:

# Our Target CR:
metadata:
  name: mgc-spine-1  # <-- CR name

# With targetName: true
# SDC would send: target: "mgc-spine-1"

# But SONiC expects: target: "OC-YANG"
# Result: FAILS - SONiC doesn't recognize "mgc-spine-1" as a valid namespace

Proposed Solution

Could we use a string field instead of (or in addition to) a boolean?

Option A: Simple String Field

// GNMITarget specifies the target field value in gNMI Path prefix
// Examples: "OC-YANG" (SONiC), "openconfig" (some vendors), or empty
// +optional
GNMITarget *string `json:"gnmiTarget,omitempty"`

Usage:

# For SONiC (literal string):
spec:
  gnmiTarget: "OC-YANG"

# For other vendors that don't need it:
spec:
  # gnmiTarget not specified - no target sent

Option B: String with Template Support

GNMITarget *string `json:"gnmiTarget,omitempty"`

Usage:

# For SONiC (literal string):
spec:
  gnmiTarget: "OC-YANG"

# For devices wanting Target CR name:
spec:
  gnmiTarget: "{{.TargetName}}"

# For devices wanting namespace/name:
spec:
  gnmiTarget: "{{.Namespace}}/{{.TargetName}}"

Option C: Combined Boolean + String

// UseTargetName sends Target CR name as gNMI target (for devices that support it)
UseTargetName *bool `json:"useTargetName,omitempty"`

// GNMITarget specifies explicit target value (overrides useTargetName)
// Use for devices like SONiC that require specific values ("OC-YANG")
GNMITarget *string `json:"gnmiTarget,omitempty"`

Impact

This would enable SDC to work with:

Vendor	Target Value	Config
Dell SONiC Enterprise	OC-YANG	gnmiTarget: "OC-YANG"
SONiC Community	OC-YANG	gnmiTarget: "OC-YANG"
Devices wanting CR name	<target-name>	gnmiTarget: "{{.TargetName}}" or useTargetName: true
Devices not needing target	(empty)	(field omitted)

References

• SONiC gNMI Usage Examples - Shows -xpath_target OC-YANG requirement
• OpenConfig gNMI Specification - Path.target
• SONiC Management Framework

Ready to Help Test

We have 4 SONiC switches deployed and ready for testing. Happy to validate any implementation approach you choose!

Let me know if you need any additional information about the SONiC gNMI behavior.

[henderiw]

Thx for sharing the use case. I was too fast, the proposal should have been a string iso bool

TargetName *string json:"targetName,omitempty" yaml:"targetName,omitempty" protobuf:"varint,9,opt,name= targetName"
}