View source for NS Deployment with OSM, MAAS, and RPI

== Introduction ==
Network function virtualization (NFV) is a way to visualize network service that have traditionally been run on proprietary hardware. NFV relies on a software framework called NFV MANO (Management and Orchestration) to deploy and maintenance network service. Current most popular NFV MANO is Open Source MANO maintained by ETSI.

We are going to use OSM to deploy and measure NS performance on a cluster of RPI. However, since OSM does not have a plugin for MAAS yet. We also need to build a simple plugin for our testing purpose. More information about the plugin is available at the example section. 

== RPI network diagram ==
We are going to use the following network setup for our RPI cluster: [[RPI-MAAS-network-diagram]].

== Components ==
#OSM (Open Source MANO): Is a NFV Management and Orchestration Framework tool. We use OSM to manage the whole network service lifecycle (Day0-2). OSM consists of many sub component to interact with other services for managing the whole NFV lifecycle.
##RO (Resource Orchestration): For managing Day0 tasks of instantiate and provisioning a machine. RO itself also contains multiple modules or plugin to interact with different cloud system. For our case, we develop a plugin for it to interact with MAAS clouds. The plugin is called RO_VIM_MAAS, it will allow OSM to interact with MAAS to instantiate and provision a machine for Day0 network service configuration.  
##LCM (Live Cycle Management): Responsible for Day1-2. LCM uses JuJu to manage Day1-2 through JuJu Charms (Charms is set of actions to run against a machines for provisioning and configuration purpose). The JuJu parent module are called VCA (VNF Configuration & Abstraction).
#MAAS: Metal-as-a-Service (MASS) is a bare-metal cloud provisioning software. We use MAAS to provision our cluster of RPi for network service deployment. 
#JuJu: JuJu is an application modeling tool. OSM uses JuJu for Day1-2 operations of network services. 
#RPI: Raspberry PI.

== Objective ==

== Deployment architecture ==
The NS deployment follows 3 days process. All 3 days process can be summarized as follows: 
* Day0: VNF Instantiation & Management setup
This is the first of 3 steps, it prepares infrastructure for network service by deploying the operating system, configuring user authentication (SSH, login), reading network connection, etc. In this step, OSM extracts deployment specs (OS, CPU, RAM, Network, etc.), cloud-init script, and sends to MAAS (RO-VIM Plugin) to select a machine, deployment OS image, and run cloud-init. Once deployed, OSM will get the machine management IP address (accessible from OSM). This IP address is for the Day1-2 configuration.
* Day1: VNF Services Initialization: 
The goal of Day1 is to install the software on the deployed OS from Day0. The JuJu Charms is used to define actions for: install software, start service, update config, stop service, relate multiple applications (Exchange data between applications such as: IP, Port, Auth, etc.), collect metrics, etc.
* Day2: VNF Runtime Operations: 
After completing Day1, JuJu still continues to monitor the deployed applications, collect metrics, and run Charm actions (custom actions run manually by users).

More information about VNF onboarding: https://osm.etsi.org/docs/vnf-onboarding-guidelines/00-introduction.html

The deployment architecture starts from the top to the bottom (Day0, Day1, and Day2)
[[File:OSM MAAS RPI architecture.png|NS deployment architecture]]

== Example Deployment ==
To deploy a NS with OSM, we need to create a NS Package and VNF Package that contains: NS descriptor, VNF descriptor, JuJu Charms, cloud-config, etc.

To quickly getting start with NS deployment, we can use the example NS packages in this repository: [https://osm.etsi.org/gitlab/vnf-onboarding/osm-packages](https://osm.etsi.org/gitlab/vnf-onboarding/osm-packages) 

In this example, we will use the "native_charm_ns" and "native_charm_vnf" to deploy a NS with JuJU Native Charms, the charm only have one action called "touch", which allow user to execute it to create a file in the VDU. The two packages are available here: [https://osm.etsi.org/gitlab/vnf-onboarding/osm-packages/-/tree/master/charm-packages/native_charm_ns](https://osm.etsi.org/gitlab/vnf-onboarding/osm-packages/-/tree/master/charm-packages/native_charm_ns) and here: [https://osm.etsi.org/gitlab/vnf-onboarding/osm-packages/-/tree/master/charm-packages/native_charm_vnf](https://osm.etsi.org/gitlab/vnf-onboarding/osm-packages/-/tree/master/charm-packages/native_charm_vnf)

Because our MAAS setup has different image and network setup, we will modify the  accordingly. The modified the files are native_charm_nsd.yaml and native_charm_vnfd.yaml. And they are available here: 
[[native_charm_ns_descriptors]]

The change to original example are number of VDUs, network interfaces and VDU image name.

To upload the packages with "osm" command. osm nfpkg-create <ns_or_vnf_directory>
<pre>
osm nfpkg-create native_charm_vnf/
osm nspkg-create native_charm_ns/
</pre>

To deploy NS with OSM CLI
<pre>
osm ns-create --ns_name nativeCharmNS --nsd_name native_charm-ns --vim_account maas
</pre>

MAAS Plugin for the deployment:  
[[simple maas plugin for the example|MAAS VIM plugin for the example deployment]]

Note: For Native charm to work, OSM and RPIs need to be able to communicate with each other via the mgmt network.