Added chapter 5 (OSM usage):

- OSM talks to the VIM for the deployment of VNFs and VLs connecting them

- OSM talks to the VNFs deployed in a VIM to run day-0, day-1 and day-2 configuration primitives.

![OSM Release SIX](assets/600px-Osmtopology.png)

![OSM](assets/600px-Osmtopology.png)

In order for OSM to work, it is assumed that:

- Each VIM has a so called management network which provides IP address to VNFs

- That management network is reachable from OSM

## Install OSM Release SIX

This release expands the cloud-native, *dockerized* OSM installation with the kafka bus for asynchronous communications, a lighter orchestrator with Network Services and Slicing capabilities, performance/fault/policy management features, a SOL005-aligned NBI, an enhanced GUI with a service composer, and OSM client leveraging the unified and improved REST API that the NBI exposes.

## Installing OSM

### Default installation procedure

All you need to run OSM Release SIX is a single server or VM with the following requirements:

All you need to run OSM is a single server or VM with the following requirements:

- MINIMUM: 2 CPUs, 4 GB RAM, 20GB disk and a single interface with Internet access

- RECOMMENDED: 2 CPUs, 8 GB RAM, 40GB disk and a single interface with Internet access

### Checking your installation

After some time, you will get a fresh OSM Release SIX installation with its latest, pre-built docker images which are built daily. You can access to the UI in the following URL (user:`admin`, password: `admin`): [http://1.2.3.4](http://1.2.3.4/), replacing 1.2.3.4 by the IP address of your host.

After some time, you will get a fresh OSM installation with its latest, pre-built docker images which are built daily. You can access to the UI in the following URL (user:`admin`, password: `admin`): [http://1.2.3.4](http://1.2.3.4/), replacing 1.2.3.4 by the IP address of your host.

![OSM home](assets/600px-Osm_lwb_ui_login.png)

![OSM Release SIX installation result](assets/600px-Osm_lwb_ui.png)

![OSM installation result](assets/600px-Osm_lwb_ui.png)

As a result of the installation, thirteen docker containers are created in the host (without considering optional stacks). You can check they are running by issuing the following commands:

osm ns-list

```

**Instantiation parameters can be specified using both CLI and UI. There are some examples collected in this page: [OSM instantiation parameters](06-02-instantiation-parameters.md).**

### Using old descriptors from Release TWO

Beware that old Release TWO descriptors cannot be directly used by OSM Release SIX.

You should use this **[conversion tool](03-01-create-vnf-package.md#migrating-old-descriptors-to-current-release)** to convert them to Release SIX format and **[create the corresponding package](03-01-create-vnf-package.md)**.

**Instantiation parameters can be specified using both CLI and UI. You can find a thorough explanation with examples in this page: [OSM instantiation parameters](05-osm-usage.md#advanced-instantiation-using-instantiation-parameters).**

## What's next?

# Default VNF Primitives

The following is a list of the default VNF primitives supported by OSM. These primitives, executed at Day 1 and Day 2, are the encapsulation of your operational logic.

| Primitive |            Description            | Required |                           Example                            |

| :-------- | :-------------------------------: | :------: | :----------------------------------------------------------: |

| Config    | Change the configuration of a VNF |    No    | [VNF_Primitive_Config](03-02-02-01-default-vnf-primitives-config.md) |

| Upgrade   |  Perform a VNF Software Upgrade   |    No    | [VNF_Primitive_Upgrade](03-02-02-02-default-vnf-primitives-upgrade.md) |

| Start     |       Start the VNF service       |    No    | [VNF_Primitive_Start](03-02-02-03-default-vnf-primitives-start.md) |

| Stop      |       Stop the VNF service        |    No    | [VNF_Primitive_Stop](03-02-02-04-default-vnf-primitives-stop.md) |

| Restart   |       Stop the VNF service        |    No    | [VNF_Primitive_Restart](03-02-02-05-default-vnf-primitives-restart.md) |

| Reboot    |          Reboot the VNF           |    No    | [VNF_Primitive_Reboot](03-02-02-06-default-vnf-primitives-reboot.md) |

# VNF Primitive Config

The purpose of the Config primitive is to change the configuration your VNF application.

| Config | Required |       |      |

| :----- | :------: | :---: | ---- |

| Day 0  |  Day 1   | Day 2 |      |

| No     |   Yes    |  Yes  | No   |

The Config Primitive is handled differently than Service Primitives.

The configuration parameters you'd like to make available for modification are defined in the VNF Charm's config.yaml:

```

options:

  target_latency:

    default: 100000

    description: Target request latency for overload control (microseconds)

    type: int

```

The configuration is then exposed to the operator via the VNF Descriptor:

```

```

Example code:

```

@when('config.changed')

def apply_vnf_config():

    """Runs when the config-changed hook is executed."""

    err = ''

    try:

        cfg = config()

        """

        Run the command(s) necessary to perform a safe stop of your VNF

        This could be a single command that encapsulates your stop process...

        """

        result, err = charms.sshproxy._run("/srv/myvnf/config.sh target_latency={}".format(cfg['target_latency']))

    except:

        action_fail('Restart failed:' + err)

    else:

        action_set({'outout': result})

    # Restart your VNF for the change to take affect, if necessary.

    restart_vnf()

```

For a full example of creating a VNF charm, please see [Creating your own VNF charm](03-02-00-create-vnf-charm.md).

# VNF Primitive Upgrade

The purpose of the Upgrade primitive is to perform an upgrade of operational software on your VNF.

| Config | Required |       |      |

| :----- | :------: | :---: | ---- |

| Day 0  |  Day 1   | Day 2 |      |

| No     |   Yes    |  Yes  | No   |

Example code:

```

@when('actions.upgrade')

def upgrade_vnf():

    err = ''

    try:

        """

        Run the command(s) necessary to perform a safe software upgrade of your VNF

        This could be a single command that encapsulates your upgrade process...

        Or a series of commands for each step, such as:

         - check if update is available

         - remove vnf from service

         - download

         - upgrade

         - install

         - verify or fail

         - rollback

         - return vnf to service

        """

        result, err = charms.sshproxy._run("/srv/myvnf/upgrade.sh")

    except:

        action_fail('Upgrade failed:' + err)

    else:

        action_set({'outout': result})

    finally:

        clear_flag('actions.upgrade')

```

For a full example of creating a VNF charm, please see [Creating your own VNF charm](03-02-00-create-vnf-charm.md).

# VNF Primitive Start

The purpose of the Start primitive is to start your VNF application.

| Config | Required |       |      |

| :----- | :------: | :---: | ---- |

| Day 0  |  Day 1   | Day 2 |      |

| No     |   Yes    |  Yes  | No   |

Example code:

```

@when('actions.start')

def start_vnf():

    err = ''

    try:

        """

        Run the command(s) necessary to perform a safe start of your VNF

        This could be a single command that encapsulates your start process...

        Or a series of commands for each step, such as:

         - start your vnf

         - perform warm-up operatoins

         - accept live traffic

        """

        result, err = charms.sshproxy._run("/srv/myvnf/start.sh")

    except:

        action_fail('Start failed:' + err)

    else:

        action_set({'outout': result})

    finally:

        clear_flag('actions.start')

```

For a full example of creating a VNF charm, please see [Creating your own VNF charm](03-02-00-create-vnf-charm.md).