Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Element Manager API #20
Netrino has two reasons for communicating with devices. One is for information gathering, the other for configuring. Different devices have different methods and protocols available for these purposes. The aim for Netrino is to be as flexible as possible (thus allowing multiple methods to communicate to devices, and providing the option to choose which) and as extensible as possible (allowing for future-proofing by catering for the seamless addition of new methods).
The devices on which Netrino has to orchestrate services, are referred to as elements. Netrino needs to store a list of these elements, for the purpose of making them available as options when services are to be provisioned on them.
Typically, elements will have an IP address associated, which is used for communicating with the device. However, it is foreseen that Netrino is to know about devices which it can not communicate with. An example would be a cabinet in which devices are mounted. For this reason, an IP address is not a required value when storing an element's details.
Elements should have at least a name. For servers and network devices like routers, this would eg. be the hostname. The primary key used to reference elements is a UUID, which allows one to change an element's IP and/or hostname without losing any back references.
Netrino communicates with devices through what is known as South-bound Interfaces, just referred to here as "interfaces". These interfaces are python modules. They register themselves as python entry points called netrino_interfaces to make their presence known to Netrino. Netrino comes with a couple of built-in interfaces (netconf, ansible, snmp, openstack, contrail) but also provides the ability to easily add new interfaces.