TM Implementation.

Templating Engine
The Templating Engine is responsible for managing the templates. When templates are created, they are uploaded to the object store (Katalog).

Ansible
Netrino also makes HEAT templates available for orchestration

Templating Engine
The Templating Engine is responsible for managing the templates. When templates are created, they are uploaded to the object store (Katalog).

YANG
Netrino makes use of YANG models to define Services. Although YANG was designed along side NETCONF, it can be used for any arbitrary modelling since it can be serialized into popular API notation formats such as JSON or XML.

This means not only does Netrino support your favourite vendor out of the box by loading its YANG models (if it already supports NETCONF), but you can even make provision for ones that don't by creating the YANG model and driver for it yourself.

The YANG models are stored in the object store, and a helper function is supplied that can map the module name to the namespace, to be stored for easy lookup.

Templating Engine
The Templating Engine is responsible for managing the templates. When templates are created, they are uploaded to the object store (Katalog).

JSON
Json templates, typically used alongside with REST API element interfaces.

In order to provide a service, one typically requires resources. For example, this could be things like IP address, VLAN number, device port or BGP community such as a route-target. These are collectively referred to as resources.

Netrino has a built-in resource manager for which the idea is to eventually cater for both for green field and brown field scenarios.

When creating a resource pool, it is given a type (eg. IPv4) and a range. The actual resource usage is stored in a different table that references this pool. In the brown-fields scenario, whenever an element is :ref:updated <update>, the resource usage is updated.

When designing a :ref:service <services>, the chosen YANG models are scanned for type definitions. Certain types can be linked to resource pools. For example, the RFC 6991 type definition of ipv4-address is linked to IPv4 resource pools. As such, the resource pools can be associated to those entries in the YANG models so that the entries can be automatically assigned from the next available resource in the pool when a :ref:Service is requested <service_request>.

Resource pools thus have an optional associated list of YANG type definitions.

Resource pools can be globally significant (e.g. public IPv4's) or element-significant (eg. VLANS on a switch). Unless specified otherwise, global is assumed. If locally significant is specified during the creation/updating of a resource pool, then the element or element tag has to be specified that this resource pool is linked to.

Elements can also be resources. When elements are to be auto-allocated, an element tag must be associated to the specific YANG model in the :ref:service <services>.

Manage VM Instances. CRUD.

Templating Engine
The Templating Engine is responsible for managing the templates. When templates are created, they are uploaded to the object store (Katalog).

TEXT
Text templates can be used for example when the underlying element interface can take configuration snippets as input. For example napalm's load_merge() method.

Templating Engine
The Templating Engine is responsible for managing the templates. When templates are created, they are uploaded to the object store (Katalog).

XML templates.

TMForum application

TM Application

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.

Templating Engine
The Templating Engine is responsible for managing the templates. When templates are created, they are uploaded to the object store (Katalog).

HEAT

Netrino also makes HEAT templates available for orchestration.

TM HUB Feature Sync.

Singal to the SNMP Receiver from Yoshii

Create a Service Scheduler for Netrino , where Service Requests can be scheduled ahead of time. The Service Scheduler supports once-off Service Request creation, as well as recurring creation of Service Requests.

Need the ability for Netrino to provision on Openstack