The DiscoveryRule CustomResource#

The DiscoveryVendorProfile defines the provider specific information that uniquely identify the provider, version together with additional metadata (such as platformType, hostname, serial-number and mac Address)

Curently we support gnmi, but other protocols are envisioned to be supported going forward.

Attributes#

gnmi:
- organization: organization matches the gnmi capabilities organization
- modelMatch: if an organization has multiple NOS(es) it can distibuish the provider using a unique key in the model
- encoding: the gnmi encoding used to get the paths (default: JSON_IETF, other: JSON, PROTO, ASCII)
- paths: slice/list to identify the key (fixed mapping to the target information in the target CR)
  - key: supported keys are version, platform, hostname, serialNumber, macAddress
  - path: gnmi path related to the key (the path can contain the keys or not)
  - regex: used to transform the retrieved data
  - script: starlark script to transform the retrieved data (used after regex in sequence)

How gnmi discovery works#

A gNMI Capabilities Request is send

The organization field in the capabilities identifies the provider.
If the vendor supports multiple Network OS (NOS) options, modelMatch is used to distinguish them.

Once the NOS is identified, additional device parameters (e.g., version, MAC address, serial number, and platform) are retrieved using gNMI paths defined in DiscoveryVendorProfile.

for each provided path the retrieved data can be transformed using regex and starlark function before it is being used to update the target CR.

If discovery is successful, the extracted parameters are reflected in the Target CR.

The version and provider are important as they are used to match the schema

Examples#

apiVersion: inv.sdcio.dev/v1alpha1
kind: DiscoveryVendorProfile
metadata:
  name: srl.nokia.sdcio.dev
  namespace: default
spec:
  gnmi:
    organization: Nokia
    modelMatch: nokia.com:srlinux
    #encoding: PROTO
    paths:
      # Some vendors return a JSON IETF blob of data with a different gNMI path than the requested one if keys are not specified.
      # Make sure to include keys in the XPATH when the encoding is JSON_IETF. Alternatively use PROTO or ASCII encoding.
    - key: version
      path: platform/control[slot=A]/software-version
      regex: ^v?(\d+\.\d+\.\d+)
    - key: platform
      path: platform/chassis/type
    - key: hostname
      path: system/name/host-name
    - key: serialNumber
      path: platform/chassis/serial-number
    - key: macAddress
      path: platform/chassis/hw-mac-address

apiVersion: inv.sdcio.dev/v1alpha1
kind: DiscoveryVendorProfile
metadata:
  name: eos.arista.sdcio.dev
  namespace: default
spec:
  gnmi:
    organization: "Arista Networks, Inc."
    paths:
    - key: version
      path: components/component/state/software-version
      regex: ^v?(\d+\.\d+\.\d+[A-Za-z]?)
    - key: platform
      path: components/component/state/part-no
    - key: hostname
      path: system/state/hostname
    - key: serialNumber
      path: components/component/state/serial-no
    - key: macAddress
      path: lldp/state/chassis-id

apiVersion: inv.sdcio.dev/v1alpha1
kind: DiscoveryVendorProfile
metadata:
  name: sros.nokia.sdcio.dev
  namespace: default
spec:
  gnmi:
    organization: Nokia
    modelMatch: nokia-conf
    paths:
    - key: version
      path: state/system/version/version-number
      regex: ^\w?-(\d+.\d+\.R\d+)
    - key: platform
      path: state/system/platform
    - key: hostname
      path: state/system/oper-name
    - key: serialNumber
      path: state/chassis/hardware-data/serial-number
    - key: macAddress
      path: state/system/base-mac-address