manuals/developer-guide/src/main/asciidoc/topoprocessing/odl-topoprocessing-inventory-rendering-dev.adoc

   1 ==== Overview
   2 With incoming release change, which sets opendaylight-Inventory model as deprecated, comes request to render (translate) data from inventory model (whether augmented or not) to another model for further processing. Topology Processing Framework can be adjusted to bring this functionality by implementing several render-specific classes. This chapter is step by step guide how to implement your own topology rendering according to our inventory rendering demo.
   3
   4 ==== Use case
   5 For the purpose of this guide we are going to render following augmented fields from Openflow model:
   6
   7 * from Inventory Node:
   8 ** manufacturer
   9 ** hardware
  10 ** software
  11 ** serial-number
  12 ** description
  13 ** ip-address
  14 * from Inventory Node-connector:
  15 ** name
  16 ** hardware-address
  17 ** current-speed
  18 ** maximum-speed
  19
  20 We also want to preserve node id and termination-point id from opendaylight-topology-inventory model (which is Network Topology part of Inventory model).
  21
  22 ==== Implementation
  23 There are two ways to implement support for your specific topology-rendering:
  24
  25 * add module to your project using dependency on Topoprocessing Framework
  26 * add module to Topoprocessing Framework itself
  27
  28 Regardless of chosen way, successfull implementation requires to fulfill all of the following steps:
  29
  30 ===== Step1 - Target model creation
  31 Because Network Topology doesn't have fields to store all desired data, it is necessary to create new model which will data be rendered to. For this guide we created inventory-rendering model. In picture below is shown how data will be rendered and stored.
  32
  33 .Rendering to inventory-rendering model
  34 image::topoprocessing/Inventory_Rendering_Use_case.png[width=500]
  35
  36 IMPORTANT: In case of implementing your version of topology-rendering into Topology Processing Framework, source file of model (.yang) must be saved in /topoprocessing-api/src/main/yang folder so corresponding structures can be generated during build and can be accessed from every module through dependecies.
  37
  38 When target model is created you have to add identifier through which you can set your new model as output model. To do that you have to add another identity item to topology-correlation.yang file. For our inventory-rendering model identity looks like this:
  39
  40 [source,yang]
  41 ----
  42 identity inventory-rendering-model {
  43         description "inventory-rendering.yang";
  44         base model;
  45 }
  46 ----
  47
  48 After that you will be able to set inventory-rendering-model as output model in xml.
  49
  50 ===== Step2 - Module and feature creation
  51 IMPORTANT: This and following steps are based on implemented Model specific approach in Topology Processing Framework. We highly recommend to get familiar with this approach in advance.
  52
  53 To create base module and add it as a feature to karaf in Topology Processing Framework we have made changes contained in following https://git.opendaylight.org/gerrit/#/c/26223/[commit]. Changes in other projects will be probably similar.
  54
  55 //TBD: files table
  56
  57 ===== Step3 - Module adapters creation
  58 There are seven mandatory interfaces or abstract classes that needs to be implemented in each module. They are:
  59 //TBD
  60
  61 ==== Testing
  62 If you want to test our implementation it is required to apply https://git.opendaylight.org/gerrit/#/c/26612[this patch]. It adds openflowplugin dependency so we can use it in karaf distribution as feature.
  63 //TBD