From 1d8163dbf8b1ecbee847717f1461dac982ff8281 Mon Sep 17 00:00:00 2001 From: S237035 Date: Mon, 4 May 2020 14:20:11 +0200 Subject: [PATCH 1/3] added Arista SDN plugin info --- 03-developer-how-to-for-modules.md | 90 ++++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+) diff --git a/03-developer-how-to-for-modules.md b/03-developer-how-to-for-modules.md index 73d12a3..6d75e1e 100644 --- a/03-developer-how-to-for-modules.md +++ b/03-developer-how-to-for-modules.md @@ -309,6 +309,96 @@ simple_multi_vnfc simple_linux ``` +### Creating a new SDN/WIM plugin +(DRAFT) + +Choose a name, eg. XXX +Create a new plugin folder RO-SDN-XXX. Copy one of the existing, there are several connectors already created to be used as example as DYNPAC and TAPI. 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 OSM SDN callbacks to implement by the SDN plugin are: +- create_connectivity_service +- get_connectivity_service_status +- edit_connectivity_service +- delete_connectivity_service +- check_credentials +- get_all_active_connectivity_services +- clear_all_connectivity_services + +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, it must be defined in the files: +- osm/RO/RO-SDN-XXX/Makefile +- osm/RO/RO-SDN-XXX/requirements.txt +- osm/RO/RO-SDN-XXX/stdeb.cfg +- osm/RO/RO-SDN-XXX/setup.py, the class entry point has to be defined in `entry_points`, and the dependencies requirements in `install_requires` +- osm/RO/RO-SDN-XXX/debian/python3-osm-rosdn-XXX.postinst, for those libraries without a defined package in Debian + +#### Arista SDN assist module +The plugin implements the methods in order to use the resources provided by the Arista CloudVision controller. + +The communication protocol to Arista CloudVision is made through a REST API, that has been wrapped in a python library `https://github.com/aristanetworks/cvprac`, this `cvprac` library is the one used by the Arista plugin to communicate OSM with Arista CloudVision. + +In order to centralize the management and operation of the deployed Arista switches in the company, the Arista CloudVision product is deployed. The main features of Arista CloudVision is to a serve as a configuration repository, change control, and operation and monitoring tool. + +All the switch configuration is defined as a set of snippet of configuration lines, that are called `configLet` +The switches are associated in a hierarchy to a virtual parent container where all the devices of that type or organization are associated, CloudVision also allows to assign configlet to this element in order to be applied to all the elements within the hierarchy, but the plugin associates the snippet to the final switch directly. + +In the Arista plugin initialization process the switches to configure are read from the `config` parameter: + - The port mapping is searched first if it is available + - It's possible to setup switch's specific parameters using the `switches` field in the `config`, the default values for + - `usr` and `pass` are read from the plugin initialization + - Loopback (`Lo0`) and autonomous system number (`AS`) from the switch (using jsonRPC calls) + - `ip`, if it is not present the Arista CloudVision inventory is used to obtain it. + - If the switches list can not be obtained from the `config` parameter, it is obtained in the Arista CloudVision inventory looking for those switches: + - with topology_type tag set to 'leaf' or + - whose parent container is 'leaf' or + - hostname contains with 'leaf' + +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` in the methods `__configlet_modify` and `__device_modify` + - Automatically a task is created when this association is created (in 'Pending' state) + - by calling the method `__exec_task` the tasks are executed so that the configuration is applied to the switch in the, 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 rollbacked using the same methods, but setting the delete flag +- The service information is returned in the response of the creation and edition calls, so that OSM saves it, and use it in other calls for the same connectivity service + - All created services identification is 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. + +The cvprac API calls used in the plugin are: +- in `check_credentials` and `__get_Connection` + - get_cvp_info +- 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 +- jsonrpclib-pelix +- uuid +- cvprac + ## Developer Guide for OpenVIM ### Getting Started -- GitLab From 3290673dde839c9a4d3fac1657143a83b0c5e9f9 Mon Sep 17 00:00:00 2001 From: S237035 Date: Mon, 18 May 2020 16:13:02 +0200 Subject: [PATCH 2/3] update revision comments --- 03-developer-how-to-for-modules.md | 18 ++---------------- 1 file changed, 2 insertions(+), 16 deletions(-) diff --git a/03-developer-how-to-for-modules.md b/03-developer-how-to-for-modules.md index 6d75e1e..16c87ef 100644 --- a/03-developer-how-to-for-modules.md +++ b/03-developer-how-to-for-modules.md @@ -317,26 +317,12 @@ Create a new plugin folder RO-SDN-XXX. Copy one of the existing, there are seve 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 OSM SDN callbacks to implement by the SDN plugin are: -- create_connectivity_service -- get_connectivity_service_status -- edit_connectivity_service -- delete_connectivity_service -- check_credentials -- get_all_active_connectivity_services -- clear_all_connectivity_services - 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, it must be defined in the files: -- osm/RO/RO-SDN-XXX/Makefile -- osm/RO/RO-SDN-XXX/requirements.txt -- osm/RO/RO-SDN-XXX/stdeb.cfg -- osm/RO/RO-SDN-XXX/setup.py, the class entry point has to be defined in `entry_points`, and the dependencies requirements in `install_requires` -- osm/RO/RO-SDN-XXX/debian/python3-osm-rosdn-XXX.postinst, for those libraries without a defined package in Debian +If the plugin has any third party dependent library, it must modify these files, within the chosen plugin name, Makefile, setup.py. Set the python dependencies at requirements.txt, setup.py, and debian package dependencies at stdeb.cfg #### Arista SDN assist module -The plugin implements the methods in order to use the resources provided by the Arista CloudVision controller. +The plugin uses Arista CloudVision controller to manage the Arista switches. The communication protocol to Arista CloudVision is made through a REST API, that has been wrapped in a python library `https://github.com/aristanetworks/cvprac`, this `cvprac` library is the one used by the Arista plugin to communicate OSM with Arista CloudVision. -- GitLab From 5d5e2b5466a6c2b111a88b85380b87f997048005 Mon Sep 17 00:00:00 2001 From: S237035 Date: Wed, 20 May 2020 13:39:42 +0200 Subject: [PATCH 3/3] Added topology, reviewed. --- 03-developer-how-to-for-modules.md | 62 +++++++++++++----------------- 1 file changed, 26 insertions(+), 36 deletions(-) diff --git a/03-developer-how-to-for-modules.md b/03-developer-how-to-for-modules.md index 16c87ef..0519a5e 100644 --- a/03-developer-how-to-for-modules.md +++ b/03-developer-how-to-for-modules.md @@ -310,55 +310,49 @@ simple_linux ``` ### Creating a new SDN/WIM plugin -(DRAFT) - -Choose a name, eg. XXX -Create a new plugin folder RO-SDN-XXX. Copy one of the existing, there are several connectors already created to be used as example as DYNPAC and TAPI. 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. +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, it must modify these files, within the chosen plugin name, Makefile, setup.py. Set the python dependencies at requirements.txt, setup.py, and debian package dependencies at stdeb.cfg +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 communication protocol to Arista CloudVision is made through a REST API, that has been wrapped in a python library `https://github.com/aristanetworks/cvprac`, this `cvprac` library is the one used by the Arista plugin to communicate OSM with Arista CloudVision. +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'. -In order to centralize the management and operation of the deployed Arista switches in the company, the Arista CloudVision product is deployed. The main features of Arista CloudVision is to a serve as a configuration repository, change control, and operation and monitoring tool. +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. -All the switch configuration is defined as a set of snippet of configuration lines, that are called `configLet` -The switches are associated in a hierarchy to a virtual parent container where all the devices of that type or organization are associated, CloudVision also allows to assign configlet to this element in order to be applied to all the elements within the hierarchy, but the plugin associates the snippet to the final switch directly. +It is possible to provide specific parameters for each switch using the `switches` field in the `config`: -In the Arista plugin initialization process the switches to configure are read from the `config` parameter: - - The port mapping is searched first if it is available - - It's possible to setup switch's specific parameters using the `switches` field in the `config`, the default values for - - `usr` and `pass` are read from the plugin initialization - - Loopback (`Lo0`) and autonomous system number (`AS`) from the switch (using jsonRPC calls) - - `ip`, if it is not present the Arista CloudVision inventory is used to obtain it. - - If the switches list can not be obtained from the `config` parameter, it is obtained in the Arista CloudVision inventory looking for those switches: - - with topology_type tag set to 'leaf' or - - whose parent container is 'leaf' or - - hostname contains with 'leaf' +- 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` in the methods `__configlet_modify` and `__device_modify` - - Automatically a task is created when this association is created (in 'Pending' state) - - by calling the method `__exec_task` the tasks are executed so that the configuration is applied to the switch in the, 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 rollbacked using the same methods, but setting the delete flag -- The service information is returned in the response of the creation and edition calls, so that OSM saves it, and use it in other calls for the same connectivity service - - All created services identification is 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 `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 + - 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 + - get_configlet_by_name: - add_note_to_configlet - execute_task - in `__rollbackConnection`, `__configlet_modify` and `__device_modify` are invoked @@ -379,11 +373,7 @@ The cvprac API calls used in the plugin are: - in `__load_inventory` - get_inventory -This SDN plugin needs the following external libraries: -- requests -- jsonrpclib-pelix -- uuid -- cvprac +This SDN plugin needs the following external libraries: `requests`, `uuid`, `cvprac` ## Developer Guide for OpenVIM -- GitLab