Creating your own VNF charm (Release FIVE)
DISCLAIMER: This page is being updated to reflect changes required for Release FIVE.
What is a VNF charm
A charm is a collection of scripts and metadata that encapsulate the distilled DevOps knowledge of experts in a particular product. These charms make it easy to reliably and repeatedly deploy applications, then scale them as required with minimal effort.
Driven by Juju, these charms manage the complete lifecycle of the application, including installation, configuration, clustering, and scaling.
Types of charm
There are three types of charms: proxy, machine, and Kubernetes.
Proxy Charm
OSM supports a limited version of charms that we call "proxy charms". These charms is responsible for doing Day 1 configuration. Configurations are mapped to Juju Actions which manage configuration within the VNFD qcow2 image (over SSH, via RESTful API, etc).
The diagram below illustrates the OSM workflow:
+---------------------+ +---------------------+
| <----+ |
| Resource | | Service |
| Orchestrator (RO) +----> Orchestrator (SO) |
| | | |
+------------------+--+ +-------+----^--------+
| | |
| | |
| | |
+-----v-----+ +-v----+--+
| <-------+ |
| Virtual | | Proxy |
| Machine | | Charm |
| +-------> |
+-----------+ +---------+
The SO directs the RO to create a virtual machine using the selected VNF image. When that has successfully completed, the SO will instantiate a LXD container, managed by Juju, with the proxy charm. The proxy charm will then communicate with the VNF virtual machine to do Day 1 configuration.
Machine Charm
These are the default type of charm. These charms are written to run on the same instance as the application. They handle the complete lifecycle of an application, from installation to removal.
Kubernetes Charm
Kubernetes charms are a new type of charm, beginning with Juju 2.5.
Support for these types of charm will be introduced with OSM Release Six. Examples of a Kubernetes charm can be found in devops/TBD, and the experimental OSM on Kubernetes installer.
Creating a charm
Setup
We recommend that you are running Ubuntu 16.04 or newer, or install snapd on the Linux distribution of your choice.
Install the charm snap, which provides the charm command and libraries necessary to compile your charm:
snap install charm
Setup your workspace for writing layers and building charms:
mkdir -p ~/charms/layers export JUJU_REPOSITORY=~/charms export LAYER_PATH=$JUJU_REPOSITORY/layers cd $LAYER_PATH
Layers
Layers are individual components that, when combined, result in a finished product. The diagram below describes what our example pingpong charm looks like, followed by a walkthrough of how it is built. The completed charm is available in the juju-charms repository.
+------------------+ | | | Layers | | | | +------------+ | | | | | | | Base | | | | | | | +------+-----+ | | | | | +------v-----+ | | | | | | | sshproxy | | +-----------------+ | | | | | | | +------+-----+ | | pingpong | | | +------------> | | +------v-----+ | | charm | | | | | | | | | vnfproxy | | +-----------------+ | | | | | +------+-----+ | | | | | +------v-----+ | | | | | | | pingpong | | | | | | | +------------+ | | | +------------------+
Create the layer for your proxy charm:
charm create pingpong cd pingpong
This will create a charm layer ready for customization:
.
├── config.yaml
├── icon.svg
├── layer.yaml
├── metadata.yaml
├── reactive
│ └── pingpong.py
├── README.ex
└── tests
├── 00-setup
└── 10-deploy
Next, modify layers.yaml to the following:
includes:
- layer:basic
- layer:vnfproxy
The metadata.yaml file describes what your charm is and sets certain properties used by Juju.
name: pingpong
summary: A service to test latency between machines.
maintainer: Adam Israel <adam.israel@canonical.com>
description: |
The pingpong charm manages the pingpong vnfd deployed by Open Source Mano.
tags:
- nfv
subordinate: false
series:
- trusty
- xenial
This means that your charm will include the basic layer, required for all charms, and the vnfproxy layer, which has been designed to aid in the development in proxy charms by implementing common functionality.
Actions
There are three pieces that make up an action: actions.yaml, which define an action, the actions/ directory where we'll place a small script that invokes the reactive framework, and the python code in reactive/pingpong.py that performs said action.
In actions.yaml, we define the actions we wish to support:
set-server:
description: "Set the target IP address and port"
params:
server-ip:
description: "IP on which the target service is listening."
type: string
default: ""
server-port:
description: "Port on which the target service is listening."
type: integer
default: 5555
required:
- server-ip
set-rate:
description: "Set the rate of packet generation."
params:
rate:
description: "Packet rate."
type: integer
default: 5
get-stats:
description: "Get the stats."
get-state:
description: "Get the admin state of the target service."
get-rate:
description: "Get the rate set on the target service."
get-server:
description: "Get the target server and IP set"
mkdir actions/
For each action, we need to create a script to invoke the reactive framework. This is a boilerplate script that will be used for every action. The first step is to create the first action script.
cat <<'EOF' >> actions/set-server
#!/usr/bin/env python3
import sys
sys.path.append('lib')
from charms.reactive import main
from charms.reactive import set_state
from charmhelpers.core.hookenv import action_fail, action_name
"""
`set_state` only works here because it's flushed to disk inside the `main()`
loop. remove_state will need to be called inside the action method.
"""
set_state('actions.{}'.format(action_name()))
try:
main()
except Exception as e:
action_fail(repr(e))
EOF
After this, make the file executable.
chmod +x actions/set-server
Next, copy this script for the remaining actions:
cp actions/set-server actions/set-rate cp actions/set-server actions/get-stats cp actions/set-server actions/set-state cp actions/set-server actions/get-rate cp actions/set-server actions/get-server
The last step is to map the action to the command(s) to be run. To do this, open up reactive/pingpong.py and add this code.
@when('actions.set-server')
def set_server():
err = ''
try:
cmd = ""
result, err = charms.sshproxy._run(cmd)
except:
action_fail('command failed:' + err)
else:
action_set({'outout': result})
finally:
remove_flag('actions.set-server')
The reactive framework, coupled with the script in the actions/ directory, maps the SO's invocation of the action to the block of code with the matching @when decorator. As demonstrated in the above code, it will execute a command via the ssh (configured automatically by the SO). You could replace with with calls to a REST API or any other RPC method. You can also run code against the LXD container running the charm.
Building
When you're ready, you can create your charm via the charm build command:
$ charm build build: Composing into /home/stone/charms build: Destination charm directory: /home/stone/charms/builds/pingpong build: Please add a `repo` key to your layer.yaml, with a url from which your layer can be cloned. build: Processing layer: layer:basic build: Processing layer: layer:sshproxy build: Processing layer: layer:vnfproxy build: Processing layer: pingpong
This combines all layers that you included, and those that they include, into a charm called pingpong, located in the ~/charms/builds directory.
VNF Descriptor
In your Virtual Network Function Descriptor (VNFD), you specify the name of the charm as demonstrated below:
vnfd:vnfd-catalog:
vnfd:vnfd:
- vnfd:id: rift_pong_vnf
vnfd:name: pong_vnf
vnfd:vnf-configuration:
vnfd:juju:
vnfd:charm: pingpong
Then the compiled charm (from the builds directory) has to be packaged with the descriptor package under the charm directory. So the ping VNF with the charm would be:
ping_vnf ├── charms │ └── pingpong ├── checksums.txt ├── icons ├── images ├── ping_vnfd.yaml ├── README └── scripts