Radiator VNF deployment manual Copyright Open System ... · 4. Preparing for Radiator VNF...

Radiator VNF deployment manual

Deployment manual for Radiator VNF 2017.1. Last revised on November 14, 2017

Copyright Open System Consultants Pty. Ltd, 2017

Table of Contents1. Introduction ....................................................................................................................................................... 1

2. Technical concepts ............................................................................................................................................ 1

2.1. Introduction to Chef ............................................................................................................................... 1

2.1.1. Chef terminology ........................................................................................................................ 1

2.1.2. Chef ............................................................................................................................................. 1

2.2. Introduction to Juju ................................................................................................................................ 2

2.2.1. Juju terminology ......................................................................................................................... 2

2.2.2. Juju .............................................................................................................................................. 2

3. Installation package contents ............................................................................................................................ 2

4. Preparing for Radiator VNF deployment ......................................................................................................... 3

4.1. Environment requirements ..................................................................................................................... 4

4.2. Setting up cloud environment ................................................................................................................ 4

5. Deploying Radiator VNF .................................................................................................................................. 5

5.1. Bootstrapping Juju controller ................................................................................................................. 5

5.2. Deploying Radiator VNF Manager ....................................................................................................... 5

5.2.1. Deploying VNFM package repository and Juju charms to controller ........................................ 6

5.2.2. Deploying version control to VNFM ......................................................................................... 6

5.2.3. Configuring version control ........................................................................................................ 7

5.2.3.1. Adding new admin users ................................................................................................. 7

5.2.3.2. Pushing cookbooks into repository .................................................................................. 8

5.2.4. Creating deployment user ........................................................................................................... 8

5.3. Creating VNF model ............................................................................................................................. 9

5.4. Configuration parameters of .yaml file ................................................................................................ 10

6. Example of deploying fixed Radiator VNF ................................................................................................... 11

6.1. Setting up repositories ......................................................................................................................... 12

6.2. Creating model for new VNF environment ......................................................................................... 13

6.3. Deploying Radiator VNF ..................................................................................................................... 14

6.4. Making simple configuration change .................................................................................................. 15

7. Example of deploying Diameter-based Radiator VNF for VoWiFi ............................................................... 16

7.1. Extracting cookbooks ........................................................................................................................... 16

7.2. Setting up repositories ......................................................................................................................... 16

7.3. Creating user ........................................................................................................................................ 17

7.4. Creating model ..................................................................................................................................... 17

7.5. Deploying VNF .................................................................................................................................... 18

7.6. Changing configuration ........................................................................................................................ 18

8. Cookbooks ....................................................................................................................................................... 20

9. Advanced concepts and examples .................................................................................................................. 22

9.1. Example of defining private OpenStack cloud .................................................................................... 22

9.1.1. Defining imagemetadata service using Simplestreams ............................................................. 23

9.1.2. Defining bootstrap configuration .............................................................................................. 24

Deployment manual for Radiator VNF2017.1. Last revised on November 14, 2017

i of ii

9.2. Creating and bootstrapping cloud manually ........................................................................................ 25

9.3. Getting URL to Juju GUI .................................................................................................................... 26

10. Abbreviations ................................................................................................................................................ 26


ii of ii

1. Introduction

1. IntroductionThis document explains how to deploy Radiator VNF.

Note

The command line commands shown in this document are merely examples. The commands, file names,

and file paths may vary depending on your environment.

2. Technical conceptsThis section introduces the basic concepts of Juju and Chef. These tools are used for deploying Radiator VNFMand Radiator VNF and we recommend that you have some basic knowledge about them.

2.1. Introduction to Chef

This section explains what is Chef and what its role is in Radiator VNF. Also some basic Chef-related terms areexplained because they are necessary for understanding Chef documentation and this document.

For more information about Chef, see Chef documentation [https://docs.chef.io/] and Chef tutorials [https://learn.chef.io/tutorials/].

2.1.1. Chef terminology

Here are explained some Chef-specific terms that are used in this document.

A node is any machine that is controlled by a Chef client. The node can be either physical, virtual, or cloudmachine.

A cookbook is a collection of recipes, files, templates, and other necessary things that define the wantedconfiguration. For more information, see About Cookbooks [https://docs.chef.io/cookbooks.html].

A recipe defines the node. It contains everything that is needed to configure that specific node. The recipes arewritten in Ruby. For more information, see About Recipes [https://docs.chef.io/recipes.html].

An attribute is a parameter that defines a specific detail of a node. For more information, see About Attributes[https://docs.chef.io/attributes.html].

A run-list defines all configuration settings that are necessary for a node. For more information, see About Run-lists [https://docs.chef.io/run_lists.html].

A template is an ERB (Embedded Ruby) template that is used for generating static text files.

Convergence is a process where the Chef client configures the node based on the information cookbooks,attributes, and run-lists provide.

2.1.2. Chef

Chef is a set of tools for managing configurations and it is supported by Radiator VNF.

With Chef, all infrastructure and configurations are written as Ruby code. This makes them testable like anyother piece of code.

In Chef terms, the user writes cookbooks that consist of recipes. The recipes describe how the serverapplications are configured. Each recipe contains resources and templates, which define the state of thesystem. With templates, you create your AAA (Authentication, Authorisation, Accounting) business logic. Thelocal Chef instances execute the recipes on each VNFC (Virtualised Network Function Component). VNFM(Virtualised Network Function Manager) triggers the execution as a part of lifecycle operation.

All VNFCs have their own cookbook, which includes recipes for each internal function.


1 of 27

https://docs.chef.io/

https://learn.chef.io/tutorials/

https://learn.chef.io/tutorials/

https://docs.chef.io/cookbooks.html

https://docs.chef.io/recipes.html

https://docs.chef.io/attributes.html

https://docs.chef.io/attributes.html

https://docs.chef.io/run_lists.html

https://docs.chef.io/run_lists.html

3. Installation package contents

2.2. Introduction to Juju

This section explains what is Juju and what its role is in Radiator VNF. Also some basic Juju-related terms areexplained because they are necessary for understanding Juju documentation and this document.

For more information about Juju, see Juju website [https://jujucharms.com/].

2.2.1. Juju terminology

Here are explained the most common Juju-specific terms that are used in this document.

A charm is a collection of scripts, which contain the necessary operations for deploying, configuring, scaling,and maintaining the cloud applications.

A cloud is a private or public cloud where the applications are deployed.

A controller is a Juju management node, which holds database of the Juju environment and other environment-specific data.

A model is an environment associated with the controller. One instance can be part of only one model. Whenbootstrapping a Juju environment, Juju creates two models:

• Controller model

This is for internal Juju use. Do not deploy applications into this model.

• Default model

This can be used for application deployment.

It is recommended that you create a separate model for each VNF (Virtualised Network Function). Doing this, itis easier to identify which model holds the particular VNF.

A bundle is a description file of the whole VNF environment. After the Juju bundle files are deployed, Jujuis responsible for application deployment, their configuration options, and machine scaling as defined in thebundle file.

2.2.2. Juju

Juju is an application modelling tool, which manages and maintains cloud infrastructures. It provisions theservers and runs Juju charms. The charms are responsible for configuring boilerplate environment where Chef isrun with application-specific cookbooks on the machines.

Juju controller is used as VNFM in Radiator VNF. It holds the model-independent applications, such as Gitserver and package repository. Radiator VNF use cases, such as Radiator VoWiFi and Radiator PCRF, areactually Juju models. Several Juju models can share common Git and package repositories. This means that theadministrators need access to only a single controller, which is used to operate multiple VNFs.

Juju also adds the relationships between the VNF components. The environment needs to be set up in correctorder and Juju relationships make it sure that certain tasks on certain components are executed after othercomponents have done the required phases.

Juju controls self-healing and automatic or manual scaling. It provides an API that is available for the externalsystems to get the system status.

Juju controller and models are deployed to a specific region in the cloud. By default, Juju spreads the instancesto all availability zones the region has.

3. Installation package contentsRadiator VNF and VNFM package includes the following files:


2 of 27

https://jujucharms.com/

4. Preparing for Radiator VNF deployment

• charms-radiator-vnfm-<version>.tar.gz

Radiator VNFM charms package. This contains the following charms:

– radiator-vnfm-git

This charm deploys Gitolite Git server. Git version control is used for storing the Chef cookbookswithin the environment. Git-based cookbooks are the most convenient way to configure RadiatorVNF and radiator-vnfm-git charm provides an easy-to-use Git server that can be used inside theenvironment.

For more information on Gitolite, see Hosting Git Repositories [http://gitolite.com/gitolite/].

– radiator-vnfm-repository

This charm deploys a simple package repository. If the nodes do not have internet access and there isno apt-repository available within the cloud environment, this charm serves the necessary packagesfor VNF nodes. With the provided package repository, you do not need a separate repository but allrequired packages are provided by Radiator VNF.

– radiator-vnfm-juju

This charm deploys the Juju client to the VNFM node.

– radiator-vnf-<role>

Each VNFC has its own charm. The charms are responsible for setting up each VNF node so that Chefand other required software are installed and configured correctly within each node.

• charms-radiator-vnf-<version>.tar.gz

Radiator VNF charms package

• cookbooks-radiator-vnf-<version>.tar.gz

Radiator VNF Chef cookbooks

• site-cookbooks-goodies-radiator-vnf-<version>.tar.gz

Example site cookbooks

• site-cookbooks-goodies-radiator-vnf-development-<version>.tar.gz

Example cookbooks package with test cases

• radiator-vnf-bundle.yaml

Example Juju bundle file

• radiator-vnf-relase-<version>-<yyyy>-<mm-<dd>.tar.gz

Radiator VNF package repository packages.

• radiator-vnf-relase-<version>-<yyyy>-<mm-<dd>.tar.gz.asc

ASCII armored PGP (Pretty Good Privacy) signature file of the Radiator VNF package repository archive

• radiator-vnf-release-<version>-<yyyy>-<mm-<dd>.tar.gz.sha256

SHA256 (Secure Hash Algorithm 256) checksum of the Radiator VNF package repository archive

4. Preparing for Radiator VNF deploymentThis section lists the prerequisites that are needed before you can deploy your Radiator VNF.


3 of 27

http://gitolite.com/gitolite/

4. Preparing for Radiator VNF deployment

4.1. Environment requirements

This section lists the operating systems and tools you need to have for Radiator VNF deployment. You needalso internet access for the administrator workstation.

Operating system

The Radiator VNF is tested and working on 64-bit Ubuntu 16.04.

Tools

Installing and using Radiator VNF requires these tools:

• Git version control

• Juju, version 2.0.3

Juju is included into Radiator VNF installation package. It is needed on the workstation, where Jujucommands are executed.

To install Juju:

$ sudo apt-add-repository -y ppa:juju/stable

$ sudo apt update

$ sudo apt install juju

Cloud environments

Radiator VNF requires a cloud environment. The following cloud environments are supported:

• OpenStack

• AWS

• Manual clouds

4.2. Setting up cloud environment

You need a cloud environment to run Radiator VNF. For more information about setting up a public cloud, seeJuju documentation:

• Clouds [https://jujucharms.com/docs/stable/clouds]

• Cloud credentials [https://jujucharms.com/docs/stable/credentials]

Juju provisions the cloud instances during the application deployment. By default, there is its own instance foreach application on the cloud.

Juju supports multiple major public clouds, such as AWS, Google cloud platform, and VMware. See thecomplete list in Juju clouds web page [https://jujucharms.com/docs/stable/clouds].

Usually Radiator VNF is deployed to a private cloud, such as OpenStack, with no internet access. Each privatecloud has its own images, customised regions, and availability zones. For more information about usingOpenStack cloud with Juju, see Section 9.1. Example of defining private OpenStack cloud on page 22.

Juju has also a manual cloud concept. This means that Juju does not provision machines automatically butthe provisioning is done manually. User must first register the servers to Juju. The servers can be OpenStackinstances, other virtual machines, or even physical hardware. After registration, Juju installs the necessarysoftware to the servers, including Juju agent. After it the servers can be used as any other Juju nodes.


4 of 27

https://jujucharms.com/docs/stable/clouds

https://jujucharms.com/docs/stable/credentials

https://jujucharms.com/docs/stable/clouds

5. Deploying Radiator VNF

5. Deploying Radiator VNFThis section describes the deployment process of Radiator VNF. At this point, you must have Juju installed anda cloud available.

5.1. Bootstrapping Juju controller

Bootstrapping creates Juju controller, which is the management node for the entire cloud environment. Itcontains a database and keeps track of all models in the environment. This section describes the creation processof one controller. For the high availability, we recommend that you create more than one controller for yoursystem.

Procedure

This is an example of bootstrapping Juju. File bootstrap.yaml is used for cloud-specific configurationoptions. For more examples and information on commands, see Creating a controller [https://jujucharms.com/docs/stable/controllers-creating].

To bootstrap Juju controller:

1. Run the bootstrapping command.

juju bootstrap <cloud to bootstrap> <controller name>

--metadata-source=<optional metadata service if private cloud>

--series=<series of the instance> --config=<optional config file for the

bootstrap>

Here is an example of the bootstrapping command.

$ juju bootstrap mycloud testcontroller

--metadata-source=/home/ubuntu/simplestreams/

--debug --bootstrap-series=xenial --config /home/ubuntu/bootstrap.yaml

--constraints="cpu-cores=2 mem=4096"

2. After the bootstrap is finished, check the Juju status.

$ juju status

The result looks this:

MODEL CONTROLLER CLOUD/REGION VERSION

default testcontroller vnfdev/RegionOne 2.0-rc3.1

APP VERSION STATUS SCALE CHARM STORE REV OS NOTES

UNIT WORKLOAD AGENT MACHINE PUBLIC-ADDRESS PORTS MESSAGE

MACHINE STATE DNS INS-ID SERIES AZ

5.2. Deploying Radiator VNF Manager

Before you begin

To prepare for VNF Manager deployment:

1. Uncompress charms-radiator-vnfm-<version>.tar.gz.


5 of 27

https://jujucharms.com/docs/stable/controllers-creating

https://jujucharms.com/docs/stable/controllers-creating


2. Switch to controller model.

$ juju switch controller

When you deploy the VNFM to the control model, it can be used by multiple VNFs

5.2.1. Deploying VNFM package repository and Juju charms to controller

Procedure

To deploy VNFM package repository and Juju charms:

1. Edit the config.yaml file to deploy the charm.

$ juju deploy ./radiator-vnfm-juju --series xenial --to 0

$ juju deploy ./radiator-vnfm-repository --series xenial --to 0

2. Add a relation between radiator-vnfm-juju and radiator-vnfm-repository charms.

$ juju add-relation radiator-vnfm-juju radiator-vnfm-repository

3. Check the status and wait until the repository charm status is in blocked state. It indicates that it is waitingfor the repository package.

juju status

The status result looks like this:

Model Controller Cloud/Region Version Notes

controller test-controller lab/RegionOne 2.0.3.1 upgrade available: 2.0.4

App Version Status Scale Charm ...

radiator-vnfm-juju waiting 1 radiator-vnfm-juju ...

radiator-vnfm-repository blocked 1 radiator-vnfm-repository ...

Unit Workload Agent Machine Public address Ports...

radiator-vnfm-juju/0* waiting idle 0 172.17.100.53 ...

radiator-vnfm-repository/0* blocked idle 0 172.17.100.53 ...

4. Upload the Radiator repository.

$ juju scp radiator-vnf-release-*

0:/opt/radiator-vnf/repositories/apt/incoming/

5. Wait until the repository is created. It usually takes 5-10 minutes but the time can vary. Use juju statuscommand to check when the both applications are ready. During the repository creation the repository staysin the blocked state. The repository is ready when the status print informs that both applications are ready.

5.2.2. Deploying version control to VNFM

Procedure

To deploy Git repository to VNFM:

1. Deploy the repository.

$ juju deploy ./radiator-vnfm-git --series xenial -- to 0


6 of 27


2. Wait until Juju asks the admin key.

3. Specify your public SSH key to access Git.

$ juju config radiator-vnfm-git git-repository-admins="<gitolite-admin-user>,

ssh-rsa <public key>"

You can supply multiple administrators and their keys, separated by semicolons. Here is an example:

admin1,ssh-rsa; admin2,ssh-rsa

5.2.3. Configuring version control

This section discusses configuration of Gitolite version control and how to push cookbooks to the repository.

Note

Before deploying VNF, make sure that the controller node's security group has port 80 open.

Default VNFM repositories

By default, radiator-vnfm-git charm generates three repositories:

• gitolite-admin

This is used for configuring Gitolite and it maintains all other repositories.

• radiator-vnf-cookbooks

These cookbooks set up the core of Radiator VNF for a specific release. Do not modify these cookbooks.

• site-cookbooks

These are the customer-specific cookbooks, which configure and extend the Radiator VNF cookbooks. Therelease package contains some example site cookbooks.

When you deploy several Radiator VNFs for one Radiator VNFM, it is necessary to create separate sitecookbooks.

Default access levels

Gitolite provides read, write, and administrative permissions to the users, which can be used to set differentaccess levels for users and groups. By default, the gitolite-admin repository has the following user groups:

• vnf-admins

VNF administrators have administrative access to radiator-vnf-cookbooks and site-cookbooksrepositories. They can read, write, and delete files and directories.

• vnf-users

VNF users have read and write access to radiator-vnf-cookbooks and site-cookbooks repositories.

• vnf-readonly

This group has only read access to radiator-vnf-cookbooks and site-cookbooks repositories.

5.2.3.1. Adding new admin users

Gitolite uses SSH keys for user authentication. The admin SSH key does not have access to radiator-vnf-cookbooks or site-cookbooks repositories by default. This section tells how to create a new SSH key andadd it to vnf-admins group. This SSH key can be used to pull the needed repositories.


7 of 27


Procedure

To add new users to the VNF admin group:

1. Generate SSH key for Git deployments and add it to Gitolite.

$ git clone git@<your vnfm node ip>:gitolite-admin

2. Copy the user key to vnf-admins group.

$ cd gitolite-admin

$ cp <user>.pub keydir/vnf-admins/

3. Commit the changes.

$ git add .

$ git commit -m "Added user key for <user> to the vnf-admins group"

$ git push

After commiting the changes, Gitolite automatically adds the new user and applies read and write access toradiator-vnf-cookbooks and site-cookbooks repositories.

5.2.3.2. Pushing cookbooks into repository

When the repositories are created, they are empty. You have to upload the Radiator VNF cookbooks and yoursite cookbooks into the repository. Radiator VNF nodes fetch the repositories and checkout the configuredversion. The commits have either an ID or tag to separate the commits from each other. We recommend to usetags because they are easy to read.

Procedure

To push the cookbooks into the repository:

1. Check out the radiator-vnf-cookbooks repository from version control.

$ git clone git@<your vnfm node ip>:radiator-vnf-cookbooks

2. Move to the directory and uncompress the provided cookbooks package to the Git repository.

$ cd radiator-vnf-cookbooks

$ tar zxvf cookbooks-radiator-vnf-<version>.tar.gz

$ git add .

$ git commit -m "Uploaded Radiator VNF cookbooks <version>"

$ git push origin master

$ git tag -a "2017.0" -m "Tagging release 2017.0"

$ git push --tags

Note

The cookbooks must be directly on the repository root.

5.2.4. Creating deployment user

Juju users have access to the Juju controller to run Juju commands and also to the Juju GUI. The users do notautomatically have SSH access to nodes. For general information about Juju users, see Juju users [https://jujucharms.com/docs/2.0/users].


8 of 27

https://jujucharms.com/docs/2.0/users

https://jujucharms.com/docs/2.0/users


Procedure

To create a new Juju user and grant access rights:

1. Create user myusecaseuser. Use only alphanumerical characters in the user name.

$ juju add-user myusecaseuser

2. Grant the user permissions to VNFM.

$ juju grant myusecaseuser write controller

3. Run Juju action to get deployment key for the environment.


$ juju run-action radiator-vnfm-juju/0 register-controller token='

<registration-key-string>'

Action queued with id: cd91d0e2-2d8a-4779-8492-573d65a87aca

4. Show the deployment key.

$ juju show-action-output 2f6cb513-45c3-40f4-8d8c-3366bd03f96b

results:

key: PXqdfGUomFfYTxBb5ELHWkDEHhcC38r8Es5i-IkPhXK-ar96U9mvkODkLtlR4MqWvcH...

status: OK

status: completed

timing:

completed: 2017-05-18 08:37:30 +0000 UTC

enqueued: 2017-05-18 08:37:28 +0000 UTC

started: 2017-05-18 08:37:29 +0000 UTC

5. Grant the write permission to the controller model.

$ juju grant myusecase-user write controller

5.3. Creating VNF model

Juju deploys VNF to default model. To change this, create a new model and deploy different VNFs to your ownmodel. You can create multiple VNF models on one controller.

Procedure

To create a new VNF model:

1. Create a configuration file for the new model.

$ $EDITOR mynewmodel.yaml

network: your_openstack_network_id

prefer-ipv6: false

firewall-mode: global

use-floating-ip: true

ssl-hostname-verification: false

default-series: xenial

2. Add the new model to Juju.

$ juju add-model mynewmodel --config mynewmodel.yaml


9 of 27


Added 'mynewmodel' model on mycloud/RegionOne with credential 'mycloudcreds'

for user 'admin'

3. Grant the user the access to the new model.

$ juju grant deployer write example-fixed

4. Switch to the new model where to deploy VNF.

$ juju switch mynewmodel

5.4. Configuration parameters of .yaml file

You can use the following application options:

• chef_run_list

This is a Chef cookbook run list. It describes the run list for each role when Chef is running. Your sitecookbook defines additional functionality for the node and you must edit this option to accommodate thenew cookbooks and attributes.

The default value is recipe[radiator_vnf::default], it just installs a node without any specific role.

• radiator_vnf_cookbooks_source

This string defines the sources for the Radiator VNF cookbooks. It is indented to be used with the RadiatorVNF Git repositories. Use semicolon to separate different sources. Here is an example of using this option:

[email protected]:radiator-vnf-cookbooks.git;

ssh://[email protected]/radiator-vnf-cookbooks.git;

[email protected]:radiator-vnf-cookbooks.git;

• radiator_vnf_cookbooks_version

This is the Git reference ID for the Radiator VNF cookbooks. It is a string that defines the version ofRadiator VNF cookbooks that are checked out from the Git repository. This supports any Git referenceID's, branches, and tags. The default value is master.

• site_cookbooks_source

This string defines the sources for the site cookbooks. It is indented to be used with the Radiator VNF Gitrepositories. Use semicolon to separate different sources. Here is an example of using this option:

[email protected]:site-cookbooks.git;

ssh://[email protected]/site-cookbooks.git;

[email protected]:site-cookbooks.git;

This is empty by default. It must be defined, if left empty an error is logged.

• site_cookbooks_version

This is the Git reference ID for the site cookbooks. It is a string that defines the version of site cookbooksthat are checked out from the Git repository. This supports any Git reference ID's, branches, and tags. Thedefault value is master.

• chef_initial_run_list

This is the initial Radiator VNF discovery phase run list for Chef. Initial Radiator VNF deployment is donein 2 phases. This option describes the run list for the initial service discovery phase. The default value is


10 of 27

6. Example of deploying fixed Radiator VNF

recipe[radiator_vnf::base],recipe[radiator_vnf::discovery], it configures the RadiatorVNF base service discovery. Usually there is no need to change this option.

• chef_log_level

This defines the logging level for the Chef Solo runs.

For more information, see chef-client documentation [https://docs.chef.io/ctl_chef_client.html].

• node_capacity_control

This integer defines the number of nodes for the control role. It is pushed directly through to the node'sattributes JSON file. The default value is 3.

• node_capacity_management

This integer defines the number of nodes for the management role. It is pushed directly through to thenode's attributes JSON file. The default value is 3.

• node_capacity_bedbint

This integer defines the number of nodes for the BEDBINT role. It is pushed directly through to the node'sattributes JSON file. The default value is 2.

• node_capacity_loadbalancer

This integer defines the number of nodes for the loadbalancer role. It is pushed directly through to thenode's attributes JSON file. The default value is 2.

• radiator_vnf_juju_user

This string defines the Juju user for the nodes. The Juju user has to be created and granted sufficient accessrights during the deployment. This is empty by default. It must be defined, if left empty an error is logged.

• radiator_vnf_juju_key

This string defines the key for the Juju user. The key for the Juju user has to be created during thedeployment. This is empty by default. It must be defined, if left empty an error is logged.

• fetch_http_cookbooks

This is a Boolean value that defines whether the cookbooks are downloaded with HTTP instead of Git. Thedefault value is false.

CAUTION

This is currently an experimental option and not intended to be used with Radiator VNFM.

6. Example of deploying fixed Radiator VNFRadiator VNF provides several ways to deploy an environment. This section guides you through an example ofdeployment. The names in this example are similar as in the example files in goodies/ directory.You can copythese commands directly to get a working Radiator VNF installation with the example business logic.

At first we start with goodies_radius_fixed cookbooks which are provided with the Radiator VNF releasepackage. See the README file for further details.

The example cookbook package contains a rake file, which is used to package a particular use case. You musthave ChefDK toolkit and be able to run rake files.


11 of 27

https://docs.chef.io/ctl_chef_client.html


6.1. Setting up repositories

The site cookbooks are necessary in Radiator VNF deployment because they have the actual business logic.Radiator VNF can be deployed without the site cookbooks and it also starts, but it does not do anything useful.The deployment package contains some example site cookbooks to start with.

The Gitolite configuration is organised into the subdirectories and the main configuration file gitolite.confincludes them:

• fragments

The files in this directory are used for configuring Gitolite.

• radiator-vnf

The files in this directory are used for configuring additional repositories, groups, and users.

• <hostname>

The files in this directory are used for configuring a particular Radiator VNFM server with the name<hostname>. Use this directory only if you need server-specific configuration.

Procedure

To set up the repositories:

1. Move into gitolite-admin directory.

$ cd gitolite-admin

2. Open conf/radiator-vnf/radiator-vnf-cookbooks.conf in an editor and remove the defaultexample site-cookbooks repository. Leave only radiator-vnf-cookbooks into the file.

3. Commit the change.

4. Add a repository and group configuration for your use case into conf/radiator-vnf/goodies-radius-fixed.conf.

repo goodies-radius-fixed-site-cookbooks

RW+ = @goodies-radius-fixed-admins

RW = @goodies-radius-fixed-users

R = @goodies-radius-fixed-readonly

5. Create the groups.

$ mkdir keydir/goodies-radius-fixed-admins

$ mkdir keydir/goodies-radius-fixed-users

$ mkdir keydir/goodies-radius-fixed-readonly

6. Add the keys to the groups.

$ cp <user>.pub keydir/goodies-radius-fixed-admins/

$ cp <user>.pub keydir/goodies-radius-fixed-users/

7. If you do not add the keys, use placeholder files in the group directories because Gitolite does not handleempty directories.

$ touch keydir/goodies-radius-fixed-readonly/.placeholder

Adding the placeholder file into goodies-radius-fixed-readonly/ is particularly important as theRadiator VNF nodes add their keys automatically into it and thus the directory must exist.


12 of 27



9. Clone the repository.

$ git clone git@<your vnfm node ip>:goodies-radius-fixed-site-cookbooks

$ cd goodies-radius-fixed-site-cookbooks

10. Uncompress your site cookbooks into the repository.

$ tar zxvf site-cookbooks-<use_case>-<version>.tar.gz


$ git add .

$ git commit -m "Uploaded site cookbooks <version>"

$ git push origin master

$ git tag -a "<version>" -m "Tagging version <version>"

$ git push --tags

6.2. Creating model for new VNF environment

By default, Juju deploys the default model to the VNF system. It is recommended to create a separate model toevery VNF.

Procedure

To create a new model:

1. Create configuration file for the new model.

$ $EDITOR mycompany-myusecase.yaml

network: your_openstack_network_id

prefer-ipv6: false



default-series: xenial

2. Add the new model to Juju.

$ juju add-model mycompany-myusecase --config mycompany-myusecase.yaml

Added 'mycompany-myusecase' model on mycloud/RegionOne with credential

'mycloudcreds' for user 'admin'

3. Grant the user access to the new model.

$ juju grant myusecase-user write mycompany-myusecase

4. Switch to the new model.

$ juju switch mycompany-myusecase

5. You can delete the default model.

$ juju destroy-model default


13 of 27


6.3. Deploying Radiator VNF

Procedure

To deploy Radiator VNF:

1. Uncompress the provided charm package.

$ tar -xvzf radiator-vnf-charms.tar.gz

2. Modify the radiator-vnf-mycompany-myusecase-bundle.yaml file to match your environment. Formore information about configuration parameters, see Section 5.4. Configuration parameters of .yaml fileon page 10

3. Check that you are on your desired model. Do not deploy VNF to the control model.

$ juju list-models

The result is this:

Model Cloud/Region Status Machines Cores Access Last connection

controller* mycloud/RegionOne available 1 2 admin just now

mycompany-myusecase mycloud/RegionOne available 0 - admin

2 hours ago

4. Change the model, if needed.

$ juju switch mycompany-myusecase

5. Deploy the VNF.

$ juju deploy radiator-vnf-mycompany-myusecase-bundle.yaml

6. Check the status.

$ juju status

When everything is ready and VNF is successfully deployed, the status response looks like this:

Model Controller Cloud/Region Version

mycompany-myusecase test-controller lab/RegionOne 2.0.3.1

App Version Status Scale Charm ...

radiator-vnf-bedbint active 2 radiator-vnf-bedbint ...

radiator-vnf-control active 3 radiator-vnf-control ...

radiator-vnf-loadbalancer active 2 radiator-vnf-loadbalancer..

radiator-vnf-management active 2 radiator-vnf-management ...

radiator-vnf-worker active 2 radiator-vnf-worker ...

Unit Workload Agent Machine Public address ...

radiator-vnf-bedbint/0* active idle 0 172.17.100.59 ...

radiator-vnf-bedbint/1 active idle 1 172.17.100.9 ...

radiator-vnf-control/0 active idle 2 172.17.100.86 ...

radiator-vnf-control/1* active idle 3 172.17.100.0 ...

radiator-vnf-control/2 active idle 4 172.17.100.109 ...

radiator-vnf-loadbalancer/0* active idle 5 172.17.100.44 ...

radiator-vnf-loadbalancer/1 active idle 6 172.17.100.12 ...


14 of 27


radiator-vnf-management/0* active idle 7 172.17.100.38 ...

radiator-vnf-management/1 active idle 8 172.17.100.87 ...

radiator-vnf-worker/0 active idle 9 172.17.100.67 ...

radiator-vnf-worker/1* active idle 10 172.17.100.32 ...

Machine State DNS Inst id ...

0 started 172.17.100.59 029c7ee6-d6bd-4f64-a33d-ddf69461ace1 ...

1 started 172.17.100.9 7d1246af-8de9-43d6-a1b5-de7ecd620299 ...

2 started 172.17.100.86 2c632916-5cfb-48fc-b1d8-f65fddad4009 ...

3 started 172.17.100.0 65122d16-da28-48b7-9657-23072fe872c5 ...

4 started 172.17.100.109 60685397-d4ab-474e-bc6f-348afe6ee3c2 ...

5 started 172.17.100.44 4a6715b7-57a8-411b-97d4-5ae83b1ff0ec ...

6 started 172.17.100.12 a954e332-8db9-4ae1-8264-8a86705fee68 ...

7 started 172.17.100.38 985eac59-7b63-4666-b86d-c76e53dc0666 ...

8 started 172.17.100.87 d7cad0d7-2e60-4f6b-b8d3-6fb015d50ba3 ...

9 started 172.17.100.67 4a76b6e8-fff8-4729-8099-318e0eb12aba ...

10 started 172.17.100.32 22c1aa6f-0ebc-4cf5-ae99-131ac66a6d52 ...

Relation Provides Consumes ...

consul_service_discovery radiator-vnf-bedbint radiator-vnf-cont...

vnf_management radiator-vnf-bedbint radiator-vnf-mana...

vnf_worker_backend radiator-vnf-bedbint radiator-vnf-work...

consul_service_discovery_peer radiator-vnf-control radiator-vnf-cont...

consul_service_discovery radiator-vnf-control radiator-vnf-load...

vnf_management radiator-vnf-control radiator-vnf-mana...

consul_service_discovery radiator-vnf-control radiator-vnf-work...

vnf_management radiator-vnf-loadbalancer radiator-vnf-mana...

vnf_worker_frontend radiator-vnf-loadbalancer radiator-vnf-work...

vnf_management_peer radiator-vnf-management radiator-vnf-mana...

vnf_management radiator-vnf-management radiator-vnf-work...

6.4. Making simple configuration change

This is an example case where the LDAP (Lightweight Directory Access Protocol) server address is changed forthe user accounts that BEDBINT (Backend Database Interface) uses.

Procedure

To change the LDAP server address:

1. Move to the site-cookbooks-repository.

2. Open demo-fixed-bedbint/attributes/ldap.rb in an editor.

3. Edit the following attribute to change the LDAP server address.

default['radiator-vnf']['bedbint']['configuration']['Backend'] =

'ldaps://10.1.2.3:636'

4. Commit the change in the version control.

$ git add demo-fixed-bedbint/attributes/ldap.rb

$ git commit -m "Changed the LDAP backend attribute"

$ git push


15 of 27

7. Example of deploying Diameter-based Radiator VNF for VoWiFi

5. Get the Git commit id.

$ git log

commit f9f1f8322a10756b8e0af3ba192f2a899ff4280f

Author: Your Name <[email protected]>

Date: Tue Apr 18 09:50:32 2017 +0300

6. Apply the change to BEDBINT nodes by using Juju configuration options. By default and duringdeployment, Juju fetches cookbooks from master branch. Use specific Git commit id's to identify theversion of the configuration you want to run on nodes.

$ juju switch example-fixed

$ juju config radiator-vnf-bedbint git_cookbook_site_branch=<commit id>

Juju fetches new configuration from Git and runs Chef with updated configuration attributes. Changes areapplied immediately after the juju config command.

7. Example of deploying Diameter-based Radiator VNF forVoWiFiThis example is quite similar to the Section 6. Example of deploying fixed Radiator VNF on page 11. Thenames in this example are similar as in the example files in goodies/ directory.You can copy these commandsdirectly to get a working Radiator VNF installation with the example business logic.

7.1. Extracting cookbooks

Procedure

To extract the cookbooks from goodies/:

1. Uncompress the cookbooks.

$ tar -zvxf radiator-vnf-goodies-site-cookbooks-development-<version>.tar.gz

2. Package one use case using the provided Rakefile. The Rakefile invokes the Berkshelf package command.

$ RADIATOR_VNF_USE_CASE=diameter-vowifi chef exec rake berkshelf:package

7.2. Setting up repositories

Procedure

To set up the repositories:

1. Move into gitolite-admin directory.

$ cd gitolite-admin

2. Open conf/radiator-vnf/radiator-vnf-cookbooks.conf in an editor and remove the defaultexample site-cookbooks repository. Leave only radiator-vnf-cookbooks into the file.

3. Commit the change.

4. Add a repository and group configuration for your use case into conf/radiator-vnf/goodies-diameter-vowifi.conf.

repo goodies-diameter-vowifi-site-cookbooks


16 of 27


RW+ = @goodies-diameter-vowifi-admins

RW = @goodies-diameter-vowifi-users

R = @goodies-diameter-vowifi-readonly

5. Create the groups.

$ mkdir keydir/goodies-diameter-vowifi-admins

$ mkdir keydir/goodies-diameter-vowifi-users

$ mkdir keydir/goodies-diameter-vowifi-readonly

6. Add the keys to the groups.

$ cp <user>.pub keydir/goodies-diameter-vowifi-admins/

$ cp <user>.pub keydir/goodies-diameter-vowifi-users/

7. If you do not add the keys, use placeholder files in the group directories because Gitolite does not handleempty directories.

$ touch keydir/goodies-diameter-vowifi-admins/.placeholder

$ touch keydir/goodies-diameter-vowifi-users/.placeholder

$ touch keydir/goodies-diameter-vowifi-readonly/.placeholder

Adding the placeholder file into goodies-diameter-vowifi-readonly/ is particularly important asthe Radiator VNF nodes add their keys automatically into it and thus the directory must exist.


7.3. Creating user

Procedure

To create the user:

1. Add the user.

$ juju add-user diameter-vowifi-user

2. Switch to the controller model.


3. Run a Juju action to get deployment key for the environment.

$ juju run-action radiator-vnfm-juju/0 register-controller

token='<registration-key-string>'

4. Grant the write permission to the controller model.

$ juju grant diameter-vowifi-user write controller

7.4. Creating model

Procedure

To create model for Radiator VNF VoWiFi environment:

1. Add the model.


17 of 27


$ juju add-model goodies-diameter-vowifi --config goodies-diameter-vowifi.yaml

2. Grant the write permission to the repository.

$ juju grant diameter-vowifi-user write goodies-diameter-vowifi

7.5. Deploying VNF

Procedure

To deploy the VNF:

1. Open radiator-vnf-goodies-diameter-vowifi-bundle.yaml in an editor.

2. Set install_sources and install_keys.

...

chef_run_list: "recipe[goodies_diameter_vowifi_worker::default]"

radiator_vnf_cookbooks_source: "git@<your vnfm node ip>:radiator-vnf-cookbooks"

radiator_vnf_cookbooks_version: "2017.0"

site_cookbooks_source: "git@<your vnfm node

ip>:goodies-diameter-vowifi-site-cookbooks"

site_cookbooks_version: "1.0.0"

radiator_vnf_juju_user: "diameter-vowifi-user"

...

3. Switch to the VoWiFi model and deploy the .yaml file.

$ juju switch goodies-diameter-vowifi

$ juju deploy radiator-vnf-goodies-radius-fixed-bundle.yaml

7.6. Changing configuration

Procedure

To make a simple configuration change:

1. Move in to the directory where you have cloned the goodies-diameter-vowifi-site-cookbooksrepository.

2. Open goodies-diameter-vowifi-bedbint/attributes/hss.rb in an editor and change theconfiguration of the nodes that are contacting to HSS (Home Subscriber Server). These nodes are serverswith BEDBINT role. The changes are made through Chef cookbook attributes and passed on to templatesthat render the actual configuration files.

The hss.rb attribute file contains some dummy configuration as an example. Remove anything you do notneed in your environment.

Most of the values are changed in the default['radiator-vnf']['bedbint']['configuration']attribute.

The realms in the DiaPeerDef attribute are used for the Diameter protocol towards HSS, in additionthere is the default['radiator']['options']['config_variables']['origin_realm']attribute, which is used in the BEDBINT configuration templates for the internal communication towardsthe workers. If you change this, you must also change the relevant settings in the worker and loadbalancer.The realm variable is used in the attribute file to set the same value in multiple attributes.


18 of 27


realm = 'internal.realm.radiator.vnf'

default['radiator']['options']['config_variables']['origin_realm'] = realm

default['radiator-vnf']['bedbint']['configuration']['DiaPeerDef']

['Origin-Host=hss.internal.example.com'] = {

'Identifier' => 'Internal_HSS_Connection',

'Initiator' => 1,

'ProductName' => 'Radiator VNF BEDBINT Diameter Relay',

'SupportedVendorIds' => [

'3GPP'

],

'AuthApplicationIds' => [

'Relay'

],

'VendorAuthApplicationIds' => [

'3GPP:3GPP SWx'

],

'OriginHost' => "bedbint-#{node['hostname']}.#{realm}",

'OriginRealm' => realm,

'DestinationRealm' => 'internal.example.com',

'DestinationHost' => 'hss.internal.example.com',

'Peer' => 'hss.internal.example.com'

}

default['radiator-vnf']['bedbint']['configuration']['AuthBy']['DiaRelay']

['DiaPeerDef'] = [

'DiaPeerDef-Identifier=Internal_HSS_Connection'

]

3. Open goodies-diameter-vowifi-loadbalancer/attributes/clients.rb in an editor andchange the configuration of the servers with loadbalancer role. The changes are made through Chefcookbook attributes and passed on to templates that render the actual configuration files.

This example sets a fictional DRA as the client for the loadbalancer.

The realms in the Peer attribute are used for the Diameter protocol towards the DRA, in addition thereis the default['radiator-vnf']['loadbalancer']['options']['config_variables']['origin_realm'] which is used in the loadbalancer configuration templates for the internalcommunication towards the workers. If you change this, you must also change the relevant settings in theworker and BEDBINT. The realm variable is used in thee attribute file to set the same value in multipleattributes.

realm = 'internal.realm.radiator.vnf'

default['radiator-vnf']['loadbalancer']['options']['config_variables']

['origin_realm'] = realm

default['radiator-vnf']['loadbalancer']['configuration']['peer']['internal-dra']

= {

'diameterIdentity' => {

'host' => "lb-#{node['hostname']}.#{realm}",

'realm' => realm,

},

'peerIdentity' => {

'host' => 'dra.internal.example.com',

'realm' => 'open.com.au',


19 of 27

8. Cookbooks

},

'address' => 'dns:internal.example.com',

'authApplicationID' => [

16777272,

16777264

],

'accountingApplicationID' => [

1

]

}

4. Open goodies-diameter-vowifi-worker/recipes/default.rb in an editor and change theconfiguration of the workers.

As the realm configuration workers are also seen in the outside world, you must change theDestination-Realm on the workers accordingly. It is also configured through an attribute, but in thisexample it is set in a recipe file instead of an attribute file. When setting attribute from a recipe file, youneed to prepend node before the attribute level.

destination_realm = 'internal.example.com'

node.default['radiator']['options']['config_variables']['destination_realm'] =

destination_realm

# It is a good habit to change the version number the changed cookbook

$ $EDITOR goodies-diameter-vowifi-worker/metadata.rb

$ $EDITOR goodies-diameter-vowifi-loadbalancer/metadata.rb

$ $EDITOR goodies-diameter-vowifi-bedbint/metadata.rb


$ git add goodies-diameter-vowifi-worker/ goodies-diameter-vowifi-loadbalancer/

goodies-diameter-vowifi-bedbint/

$ git commit -m "Changed the DRA, HSS and realm configuration via attributes and

bumped version to <version>"

$ git push

$ git tag -a "<version>" -m "Version <version>"

$ git push --tags

6. When the configuration changes are saved into the VNFM git repository, use Juju configuration optionsto apply the changes to the nodes. These options are application specific, there is not a common optionto control the version of all nodes. Instead you must do it on a per role basis. During the deployment Jujufetches the cookbooks from the master branch. You can use a specific git commit ID or tag to identify theversion you want to run on the nodes.

$ juju switch goodies-diameter-vowifi

$ juju config radiator-vnf-bedbint site_cookbooks_version="<version>"

$ juju config radiator-vnf-loadbalancer site_cookbooks_version="<version>"

$ juju config radiator-vnf-worker site_cookbooks_version="<version>"

8. CookbooksThe main function of Radiator VNF cookbooks is to install and configure Radiator VNF in the way that it isfully functional and ready for production. However, it does not have any business logic and do not handle oranswer to RADIUS or Diameter requests.


20 of 27

8. Cookbooks

In addition to the provided cookbooks, you have to write your own site cookbooks. They are also called wrappercookbooks. The site cookbooks contain your environment settings and business logic. The Radiator VNFpackage contains some example site cookbooks, which cover some specific use cases and their configuration.

For developing your own cookbooks, you need Chef version 12.15 or newer. It is included into Radiator VNFinstallation package.

The Radiator VNF package has a separate cookbook for every component:

• radiator_vnf

• radiator_vnf_worker

• radiator_vnf_management

• radiator_vnf_control

• radiator_vnf_loadbalancer

• radiator_vnf_bedbint

The dependencies specifically for Radiator VNF are:

• radiator

• osc_library

The Radiator VNF package contains several third-party cookbooks:

• chef-nginx

• chef-sugar

• chef-vault

• consul

• cron

• dnsmasq-local

• elasticsearch

• filebeat

• grafata

• hostsfile

• logrotate

• mariadb

• nginx_conf

• ntp

• poise-service

• redisio

• selinux_policy

• sysctl

• topbeat


21 of 27

9. Advanced concepts and examples

9. Advanced concepts and examplesThis section discusses some more advanced topics. There are also some specific examples.

9.1. Example of defining private OpenStack cloud

For more information about OpenStack clouds used with Juju, see OpenStack Clouds [https://jujucharms.com/docs/stable/help-openstack].

Procedure

To define your own private OpenStack cloud:

1. Create a new cloud definition file.

$ $EDITOR mycloud.yaml

YAML-file looks this:

clouds:

mycloud:

type: openstack

auth-types: [access-key, userpass]

regions:

RegionOne:

endpoint: <your keystone url> # http://mycloud.example.org:5000/v2.0

The attribute meanings in the .yaml file are the following:

• mycloud is the name of your cloud.

• type is the type of the cloud, openstack in this example

• auth-types defines the ways to authenticate with the cloud. Use either access-key or user name andpassword.

• regions defines the regions of the cloud.

• endpoint is the cloud endpoint. When using OpenStack, this is usually Horizon endpoint.

2. Add cloud to Juju.

$ juju add-cloud mycloud mycloud.yaml

The cloud name, mycloud in the previous example, must match with the cloud name defined in themycloud.yaml.

3. Check that your cloud is listed.

$ juju clouds

CLOUD TYPE REGIONS

aws ec2 us-east-1, us-west-1, us-west-2, eu-west-1, ...

aws-china ec2 cn-north-1

aws-gov ec2 us-gov-west-1

azure azure centralus, eastus, eastus2, northcentralus ...

azure-china azure chinaeast, chinanorth

cloudsigma cloudsigma hnl, mia, sjc, wdc, zrh

google gce us-east1, us-central1, europe-west1, asia-east1

joyent joyent eu-ams-1, us-sw-1, us-east-1, us-east-2, us-east-3 ...


22 of 27

https://jujucharms.com/docs/stable/help-openstack

https://jujucharms.com/docs/stable/help-openstack


rackspace rackspace dfw, ord, iad, lon, syd, hkg

localhost lxd localhost

mycloud openstack RegionOne

4. Define the credentials for your cloud. Easiest method is to get OpenStack RC-file and let Juju configureitself.

$ source mycloud-rc.sh

Please enter your OpenStack Password:

$ juju autoload-credentials

Looking for cloud and credential information locally...

1. openstack region "RegionOne" project "my-project" user "clouduser" (new)

2. (new)

Select a credential to save by number, or type Q to quit: 1

Select the cloud it belongs to, or type Q to quit [mycloud]:

Saved openstack region "RegionOne" project "my-project" user

"clouduser" to cloud mycloud

1. openstack region "RegionOne" project "my-project" user "clouduser"

(existing, will overwrite)

2. (new)

Select a credential to save by number, or type Q to quit: q

9.1.1. Defining imagemetadata service using Simplestreams

By default, Juju fetches images and image metadata from public Internet. When using OpenStack, you mustcreate your own image metadata, then Juju uses correct images when launching the instances to the OpenStack.We use Simplestreams in this example. Simplestreams can be used also as a service and container in OpenStack.For more information about Simplestreams, see Set up a Private OpenStack Cloud using Simplestreams [https://jujucharms.com/docs/2.0/howto-privatecloud].

Procedure

To define imagemetadata service:

1. Create the directory structure.

$ mkdir -p ~/simplestreams/images

2. Create image metadata.

$ juju metadata generate-image -d ~/simplestreams -i $IMAGE_ID -s $OS_SERIES -r

$REGION -u http://$KEYSTONE_IP:5000/v2.0/

3. Get IMAGE_ID from keystone and make sure that it matches the OS_SERIES.

$ juju metadata generate-image -d ~/simplestreams -i

4ab9bb2a-0356-4828-94e9-17cd3d5ed0a1 -s

xenial -r RegionOne -u http://mycloud.example.org:5000/v2.0

After this, file ~/simplestreams/images/streams/v1/com.ubuntu.cloud-released-imagemetadata.json looks like this:

{


23 of 27

https://jujucharms.com/docs/2.0/howto-privatecloud

https://jujucharms.com/docs/2.0/howto-privatecloud


"products": {

"com.ubuntu.cloud:server:16.04:amd64": {

"version": "16.04",

"arch": "amd64",

"versions": {

"20161013": {

"items": {

"4ab9bb2a-0356-4828-94e9-17cd3d5ed0a1": {

"id": "4ab9bb2a-0356-4828-94e9-17cd3d5ed0a1",

"region": "RegionOne",

"endpoint": "http://mycloud.example.org:5000/v2.0"

}

}

}

}

}

},

"updated": "Thu, 13 Oct 2016 06:08:54 +0000",

"format": "products:1.0",

"content_id": "com.ubuntu.cloud:custom"

}

File ~/simplestreams/images/streams/v1/index.json looks like this:

{

"index": {

"com.ubuntu.cloud:custom": {

"updated": "Thu, 13 Oct 2016 06:08:54 +0000",

"format": "products:1.0",

"datatype": "image-ids",

"cloudname": "custom",

"clouds": [

{

"region": "RegionOne",

"endpoint": "http://mycloud.example.org:5000/v2.00"

}

],

"path": "streams/v1/com.ubuntu.cloud-released-imagemetadata.json",

"products": [

"com.ubuntu.cloud:server:16.04:amd64"

]

}

},

"updated": "Thu, 13 Oct 2016 06:08:54 +0000",

"format": "index:1.0"

}

Other option is to host a basic HTTP server on your environment and keep the metadata service there. Copy thecreated simplestream/images directory structure to that server and make it accessible to the Juju controller.

9.1.2. Defining bootstrap configuration

Allocate floating IP addresses for the project in Horizon before Juju can assign them to the nodes.


24 of 27


Procedure

To define the bootstrap configuration, execute the following command:

$ $EDITOR bootstrap.yaml

The file content looks like this:

# Enable "default" secgroup as part of security group rules

use-default-secgroup: true

# This is your OpenStack network ID to which the VNF should be deployed

network: 0ec7b8c0-1636-45f2-89f0-ead2eeb712e1

# Whether to assign IPv6 address to instances (dual-stack)

prefer-ipv6: false

# Juju will use one security group for all applications


# Whether to assign automatically floating-ip for all instances deployed


9.2. Creating and bootstrapping cloud manually

Usually Juju creates virtual machines automatically when they are used. When deploying an application, Jujucreates a new instance first and then deploys new application to that instance. Scaling in and out is done also inthe similar way.

Instead of automatic scaling, you can also add servers to Juju manually. This is called manual cloud. There aresome requirements for using manual clouds:

• You need at least 2 machines.

• Virtual machines must have Ubuntu installed.

• Virtual machines must be running SSH.

• You must log in with sudo privileges to all virtual machines.

• Virtual machines must be able to communicate with each other over the network.

When using manual clouds, some Juju features are not available, such as bundle file support.

Bootstrapping cloud manually

As with other clouds, Juju needs to create a controller to manage models and other instances in the cloud.Bootstrapping process is almost similar with manual clouds and automatically created clouds. When usingmanual clouds, you must apply the network address of the machine you want to use as the controller:

$ juju bootstrap manual/[email protected] mycloud

Note

The user's public SSH key must be on the authorised-keys file on the remote machine.

Adding machines

To add machines:

juju add-machine ssh:[email protected]

Repeat this command for each machine you want to add to Juju.


25 of 27

10. Abbreviations

Deploying machines

To deploy machines to Juju:

juju deploy ./radiator-vnf-control --to 0 --config <config-file> --series xenial

juju deploy ./radiator-vnf-worker --to 1 --config <config-file> --series xenial

...

Adding units

To add units:

juju add-unit radiator-vnf-control --to 3

juju add-unit radiator-vnf-worker --to 4

...

Adding relations

Add relations with the following commands:

juju add-relation radiator-vnf-control radiator-vnf-worker

juju add-relation radiator-vnf-control radiator-vnf-management

...

The complete list of relations is in radiator-vnf-bundle.yaml.

9.3. Getting URL to Juju GUI

It is possible to use Juju through GUI. Use the following command to get the GUI URL:

$ juju gui

The result is this:

Opening the Juju GUI in your browser.

If it does not open, open this URL:

https://10.17.30.227:17070/gui/6cf3eeda-9b33-4ccb-8ac5-32e9e68db7fb/

Couldn't find a suitable web browser!

Set the BROWSER environment variable to your desired browser.

10. Abbreviations

Authentication, Authorisation, Accounting

Acronym: AAA

Backend Database Interface

Acronym: BEDBINT

Classless Inter-Domain Routing

Acronym: CIDR

Domain Name System

Acronym: DNS


26 of 27

10. Abbreviations

Embedded Ruby

Acronym: ERB

GNU Privacy Guard

Acronym: GPG

Home Subscriber Server

Acronym: HSS

Lightweight Directory Access Protocol

Acronym: LDAP

Network Time Protocol

Acronym: NTP

Pretty Good PrivacyPretty Good Privacy is an encryption program that encrypts and decrypts data.

Acronym: PGP

Secure Hash Algorithm 256

Acronym: SHA256

Virtualised Network Function

Acronym: VNF

Virtualised Network Function Component

Acronym: VNFC

Virtualised Network Function Manager

Acronym: VNFM


27 of 27

Date post:	26-Mar-2020
Category:	Documents
Upload:	others
View:	17 times
Download:	0 times

Radiator VNF deployment manual Copyright Open System ... · 4. Preparing for Radiator VNF...

Documents