(OLD) Release 0 HowTo guide for developers: Difference between revisions

From OSM Public Wiki
Jump to: navigation, search
m (link to tools page)
 
(No difference)

Latest revision as of 11:27, 22 October 2018

Architecture Overview

The OSM code is organized into four modules. The following diagram illustrates how these four components fit together:
Osm architecture.png

Launchpad (UI): Launchpad provides the user interface to the OSM orchestrator. From the Launchpad user can manage the catalog, compose the NS/VNF descriptors and perform the lifecycle management on Network Services. In addition, the UI also provides the ability execute the NS/VNF level configuration primitives. The following page describes Developer HowTo for UI Module
Service Orchestrator (SO): Service Orchestrator is responsible for End-to-End service orchestration. It is responsible for instantiating the NS, and starting the configuration plugins such as JUJU charms. The following page describes Developer HowTo for SO Module.
Resource Orchestrator (RO): Resource Orchestrator is responsible for creating and placement of compute and networking resources. It is also responsible for interfacing with SDN controller. The following page describes Developer HowTo for RO Module
Juju (CM): Juju provides the Configuration Manager for the VNFs. The Service Orchestrator interfaces with Juju server to configure the VNFs. For more information on Juju, the project is hosted on github: Juju development site. A guide for VNFs developers on how to develop Juju charms (language independent) can be found here.

references

Common Developer Guidelines

The following section provides developer guidelines across modules. For module specific guidelines refer to module specific links indicated above.

  • Please make sure that no one else is already working on an item in bugzilla before making changes. If someone is already working it, please check with the person first.
  • Similar rules applies when addressing a new feature/blueprint
  • Use meaningful comments when checking in the code
  • Use consistent conventions/style for changes to an existing module

When doing changes, be sure that you are situated in the master branch, or in the assigned branch for your change:

git checkout master


Your feedback is most welcome!
You can send us your comments and questions to OSM_TECH@list.etsi.org
Or join the OpenSourceMANO Slack Workplace
See hereafter some best practices to report issues on OSM