Developer HowTo for RO Module

Getting Started

The prefered Linux distribution is Ubuntu Sever LTS 16.04

Check out the RO module.

git clone https://osm.etsi.org/gerrit/osm/RO 

See also and follow Workflow_with_OSM_tools#Clone_your_project

New features must be incorporated to master:

git checkout master

OSM release 1 bug fixes must be done on "v1.0" branch. First time a checkout of this branch is done, use the following to associate local and origin branch

git checkout -b v1.0 origin/v1.0

Generate a ".gitignore", you can use the .gitignore-common example that skip pycharm and eclipse files

cp RO/.gitignore-common RO/.gitignore
#edit to include your local files to ignore

Prepare your git environment to push with a proper user/email, push to gerrit. See and configure:

Workflow_with_OSM_tools#Configure_your_Git_environment

Workflow_with_OSM_tools#Commit_changes_to_your_local_project

Workflow_with_OSM_tools#Push_your_contribution_to_Gerrit

Programming Language

The SO module uses Python2. However Python3 conventions for a possible future migration should be used as far as possible. For example:

BAD Python2	OK Python3
"format test string %s number %d" % (st, num)	"format test string {} number {}".format(st, num)
print a, b, c	print(a,b,c)
except Exception, e	except Exception as e
if type(x) == X:	if isinstance(x,X):

Descriptors can be YAML (prefered because more readable and allow comments) or JSON

Code Style

Please follow PEP8 style guide for all the Python code.

Logging

Use the appropriate logging levels when logging the messages. An example is shown below:

   self.log.debug("Changing state to %s", next_state)

Note that not all part of code uses this logging system, but it will be migrated soon

Exceptions

Use exceptions for the functions that fails instead of returning a negative or false value.

Note that not all part of code uses this rule, but it will be migrated soon

Directory Organization

The code organized into the following high level directories:

• / contains the openmano code
  
• /test contains scripts and code for testing
  
• /database_utils contains scripts for database creation, dumping and migration
  
• /scripts general scripts, as installation, execution, reporting
  
• /scenarios examples and templates of network scnario descriptors
  
• /vnfs examples and templates of VNF descriptors
  

RO Architecture

The RO module contains the following modules

• openmanod.py is the main program. It reads the configuration file (openmanod.cfg) and execute the httpserver and wait for the end
• nfvo.py is the main engine, implementing all the methods for the creation, deletion and management of vnfs, scenarios and instances
• httpserver.py is a thread that implements the northbound API interface, uses python bottle module
• nfvo_db.py is the module in charge of database operations. Uses MySQLdb python module
• openmano_schemas.py is a dictionary schemas used to validate API request and response content using jsonschema library
• vimconn.py is the base class for the VIM connector modules. The inherited vimconn_openstack.py and vimconn_openvim.py implements the connection to these two VIMs. Openstack ones uses the client-python libraris, meanwhile the Openvim ones uses direct http requests
• console_proxy_thread.py is a thread that implements a TCP/IP proxy for the console access to a VIM

Other modules not part of the server are:

• openmnao is a CLI client
• openmanoclient.py is a client python library for managing openmano server

Northbound Interface

The RO uses a REST API with YAML/JSON content. The primitives are explained here

Running Unit Tests

TODO

Creating a new VIM connector

Choose a name, eg. XXX

Create a new python module vimconn_XXX.py derived from vimconn.py class. Implement the relevant functions. You have two already connector created to be used as example, for openstack and openvim. Openstack connector uses the python openstack client libraries, meanwhile openvim connector uses direct http requests.

The new module can need specific configuration that it is passed as a dictionary in the config variable at constructor. For example in the case of openstack it is specify the activation or not of the port_security_enable, teh name of the physical network uses for dataplane, etc. Here you can specify those needed parameters not provided by openmano at network/image/VM creation.

Integration with the main project is automatic, just create a new datacenter of type XXX and this module will be automatically loaded. No other module of the main program need to be updated.

   openmano datacenter-create <name> <access-URL>  --type=XXX --config <specific config>
   #example of <specific config> text: "{dataplane_physical_net: physnet_sriov, port_security_enabled: False}"
   openmano datacenter-attach <name> --vim-tenant-name=<tenant-to-use-by-openmano> --user=<tenant-user> --password=<tenant-password>

You can test it using:

   #The openmano client : (you will need admin rights to create tenant, flavors,...)
   ./test_openmanoclient.py -h
   ./test_openmanoclient.py -t <working tenant> --datacenter <name> --image=<path/url of an testing image>
   
   #The vinconnector tester:
   ./test/test_vimconn.sh -h