diff --git a/03-developer-how-to-for-modules.md b/03-developer-how-to-for-modules.md index 73d12a3a04ab8efbb4c5b3996966553cb64526a5..0519a5e2d33758af8c294665e1cdfaa138b102e0 100644 --- a/03-developer-how-to-for-modules.md +++ b/03-developer-how-to-for-modules.md @@ -309,6 +309,72 @@ simple_multi_vnfc simple_linux ``` +### Creating a new SDN/WIM plugin + +Choose a name, eg. XXX. Create a new plugin folder RO-SDN-XXX. Copy one of the existing examples. Modifies `Makefile` and `setup.py` files with the chosen name. Create a class derived from `sdnconn.py`. Implement the relevant functions. DO NOT change the method names, parameters or parameter content. RO uses the same methods for all the SDNs and they cannot be changed to accommodate SDN specifics. SDN specifics must be solved inside the connector. + +The new module can need specific configuration for the SDN that it is passed as a dictionary in the *config* variable at constructor. The `config` variable is the right place to specify those needed parameters not provided by RO at the methods that form part of the SDN configuration. + +If the plugin has any third party dependent library, set the python dependencies at `requirements.txt,` `setup.py`, and debian package dependencies at `stdeb.cfg` file. + +#### Arista SDN assist module + +The plugin uses Arista CloudVision controller to manage the Arista switches. The Arista CloudVision product must be installed in order to centralize the management and operation of the deployed Arista switches. The main features of Arista CloudVision is to a serve as a configuration repository, change control, and operation and monitoring tool. The communication protocol between the OSM plugin and Arista CloudVision is made through a REST API, using the python library `cvprac` (). + +All the switch configuration is defined as a set of snippet of configuration lines, that are called `configLet`. The switches (for CloudVision a switch is called 'device') are associated in a hierarchy where all the devices of the set up are associated. CloudVision can assign configlet to to all the elements within the hierarchy, or to the final switch directly. + +In the Arista plugin the switches to configure are obtained from the `port-mapping` if supplied, and/or the `switches` read from the `config` parameter. If neither `port-mapping` nor `switches`are provided, then it is obtained in the Arista CloudVision inventory looking for those switches with topology_type tag set to 'leaf'. + +It is possible to define the topology used in the deployment, `topology` entry from the `config` parameter (`VXLAN-MLAG` default, `VXLAN`, `VLAN-MLAG`, `VLAN`). The `configLet` are built in the class AristaSDNConfigLet inside the file aristaConfigLet.py, depending on the topology used the switches configuration vary. + +It is possible to provide specific parameters for each switch using the `switches` field in the `config`: + +- Loopback (`Lo0`) and BGP autonomous system number (`AS`) +- `ip`, (not used) if it is not present the Arista CloudVision inventory is used to obtain it. + +The Arista Cloud Vision API workflow is the following: + +- When the `create_connectivity_service` or `edit_connectivity_service` methods are invoked, all the connection points are processed in order to create the configuration to apply in each switch calling the internal method `__processConnection` where: + - Then configLet are associated to the devices (leaf switches) in the method `__updateConnection` calling `__configlet_modify` and `__device_modify` methods: + - Automatically a task (in 'Pending' state) is created when this association is done. + - By calling the method `__exec_task`, tasks are executed and the configuration is applied to the switch. Internally, Arista CloudVision associates the task with a change control (with the possibility of rolling back that operation) + - In case of error all the applied operations in CloudVision are rollback. + - The service information is returned in the response of the creation and edition calls, so that OSM saves it, and supplies in other calls for the same connectivity service. + - All created services identification are stored in a generic ConfigLet 'OSM_metadata' to keep track of the managed resources by OSM in the Arista plugin. + - In the edition of a service connection, if a switch has no longer a port in the service, the configlet is deassigned from the switch and deleted. + +- When the `delete_connectivity_service` methods is invoked, it calls `__rollbackConnection` that calls `__configlet_modify` and `__device_modify` methods. (The same `__exec_tasks` operations as previously described applies) + +The cvprac API calls used in the plugin are: + +- in `check_credentials` and `__get_Connection` + - get_cvp_info: obtains general information about CloudVision +- in `get_connectivity_service_status` + - get_task_by_id +- in method `__updateConnection`, `__configlet_modify` and `__device_modify` are invoked + - get_configlet_by_name: + - add_note_to_configlet + - execute_task +- in `__rollbackConnection`, `__configlet_modify` and `__device_modify` are invoked + - execute_task +- in `__device_modify` + - get_configlets_by_device_id + - remove_configlets_from_device + - apply_configlets_to_device +- in `__configlet_modify` + - get_configlet_by_name + - delete_configlet + - update_configlet + - add_configlet +- in `__get_configletsDevices` + - get_applied_devices +- in `__addMetadata`, `__removeMetadata`, `__get_srvVLANs`, `__get_srvUUIDs` and `__get_serviceConfigLets` + - get_configlet_by_name +- in `__load_inventory` + - get_inventory + +This SDN plugin needs the following external libraries: `requests`, `uuid`, `cvprac` + ## Developer Guide for OpenVIM ### Getting Started