Device SDK Basics
The SDK is based on the OpenConfig data model. CloudVision’s support for OpenConfig-modeled data means that integrating a new device type is largely a matter of translating that device’s data to OpenConfig, and that the SDK is therefore mostly a translation layer.
This translation layer is organized as a set of Go interfaces representing a device and its APIs. There are also some implementations of these interfaces, as well as a couple of binaries that instantiate, administer, and multiplex these devices.
A provider streams out modeled data for a given target device. It knows how to interact with the device, or a system managing the device, to extract state from it. It then translates that state to an output format the Device SDK understands. Typically this will be OpenConfig-modeled data streamed out via gNMI, and for these cases there’s an interface called GNMIProvider.
For example, our SNMP provider implements GNMIProvider. It polls a target device that supports some relevant set of SNMP MIBs, translates that polled data to OpenConfig data, and streams out gNMI updates. CloudVision itself will never know that the data came from an SNMP poll; it shows up as good old OpenConfig.
A device describes how to interact with a target device: How to reach it, which providers to use, and so on. A device may model some specific target device type, specifying multiple providers that extract different sorts of data from the device using SNMP and its native CLI, say, or it may be a single-purpose device, which pulls data using just one protocol from any device that supports the protocol.
An Inventory is a list of active devices whose data we wish to stream to CloudVision.
A manager describes a device that manages a collection of target devices. Sometimes the best way to pull target device data is to do so using the API of a management system. For these cases we have managers. A Manager is instantiated with a device inventory, and adds and removes devices from the inventory as appropriate.
Tying these interfaces together is a binary called Collector. It sits between the target device and CloudVision. The Collector is configured with a set of devices or a manager. The providers specified by the device or manager stream gNMI updates and the Collector sends them on to CloudVision.
The Collector streams out its devices’ data via a gNMI interface. The device metadata (device identity, liveness information, Collector software version number, etc.) is transmitted in one of two ways. In metadata protocol version 1 (the default), this information is sent using the gRPC metadata functionality. In protocol version 2, the metadata is itself defined using a YANG model and sent using the usual gNMI updates.
The gNMI updates sent by the collector go to a binary called GNMIAdapter, which performs type-checking on incoming updates according to its supported OpenConfig models and then translates updates to CloudVision’s native streaming data format. The collector supports only the metadata protocol version 1. The GNMIAdapter is likely to be deprecated in the near future and will be replaced by the CloudVision gNMI service (see below).
The CloudVision gNMI Service (not yet released) will soon replace the collector binary and will offer a more comprehensive gNMI interface for accessing the data held in CloudVision. It will only support the metadata protocol version 2.