How to use Mgmt Driver for Ansible Driver

Overview

1. Ansible Mgmt Driver Introduction

Mgmt Driver enables Users to configure their VNF before and/or after its VNF Lifecycle Management operation. Users can customize the logic of Mgmt Driver by implementing their own Mgmt Driver and these customizations are specified by “interface” definition in NFV-SOL001 v2.6.1.

In the current community code, there is no Mgmt Driver that utilizes Ansible for VNF Configuration. Ansible is a general purpose configuration management tool when supported will benefit more users.

This user guide aims to provide users the information and procedures necessary to be able to use Ansible in Mgmt Driver.

+------------------------------------------+
| Tacker                                   |
| +--------------------------------------+ |
| |     Tacker-Server                    | |
| +--------------------------------------+ |
|                                          |
| +--------------------------------------+ |
| |   Tacker-Conductor                   | |
| |                                      | |
| | +----------------------------------+ | |
| | |         OpenStack Driver         | | |
| | +----------------------------------+ | |
| | +----------------------------------+ | |
| | | Ansible Driver                   | | |
| | |                                  | | |
| | |  +------------------+            | | |
| | |  |  Config Parser   |            | | |     1. Get VDU Resources
| | |  +--------|---------+            ------------------------------------
| | |           |                      | | |                              |
| | |           |2. VDU/Config/Command | | |                              |
| | |           |   Order Processing   | | |                              |
| | |           |                      | | |                              |
| | |  +--------V---------+            | | |                              |
| | |  |     Executor     |            | | |                 +------------|-------------+
| | |  +--------|---------+            | | |                 | Heat       |             |
| | +-----------|----------------------+ | |                 | +----------v-----------+ |
| +-------------|------------------------+ |                 | |    OpenStack Heat    | |
|               |                          |                 | +----------------------+ |
+---------------|--------------------------+                 +------------|-------------+
                |                                                         |
                |3. Execute Playbook                                      |
                |                                                         |
                |                                                         |
   +------------V-------------+                                           |
   |VNF                       |                                           |
   |     +--------------+     |                                           |
   |     |     VDU1     |     |                                           |
   |     +--------------+     |                                           |
   |                          <--------------------------------------------
   |     +--------------+     |
   |     |     VDU2     |     |
   |     +--------------+     |
   +--------------------------+

2. Use Case

  • dynamic mgmt address: The IP is generated via DHCP.

  • static mgmt address: Static IP is specified.

1. VDU Configuration at dynamic mgmt address

In helloworld3_df_default.yaml, dhcp_enabled value should be true.

tosca_definitions_version: tosca_simple_yaml_1_2
description: Simple deployment flavour for Sample VNF
imports:
  - etsi_nfv_sol001_common_types.yaml
  - etsi_nfv_sol001_vnfd_types.yaml
  - helloworld3_types.yaml
topology_template:
...
    internalNW_1:
      type: tosca.nodes.nfv.VnfVirtualLink
      properties:
      ...
          virtual_link_protocol_data:
            - associated_layer_protocol: ipv4
              l2_protocol_data:
                network_type: vlan
              l3_protocol_data:
                ip_version: ipv4
                cidr: '192.168.0.0/24'
                dhcp_enabled: true

2. VDU Configuration at static mgmt address

In helloworld3_df_default.yaml, dhcp_enabled should not be present.

tosca_definitions_version: tosca_simple_yaml_1_2
description: Simple deployment flavour for Sample VNF
imports:
  - etsi_nfv_sol001_common_types.yaml
  - etsi_nfv_sol001_vnfd_types.yaml
  - helloworld3_types.yaml
topology_template:
...
    internalNW_1:
      type: tosca.nodes.nfv.VnfVirtualLink
      properties:
      ...
          virtual_link_protocol_data:
            - associated_layer_protocol: ipv4
              l3_protocol_data:
                ip_version: ipv4
                cidr: '192.168.0.0/24'

The BaseHOT file will get the IP from the request body. This is done by defining the management IP parameter and getting its value under the properties of the resource.

parameters:
  nfv:
    type: json

  mgmt_ip_vm0_0:
    type: string
    label: Management Network IPv4 Address
    description: Management Network IPv4 Address
  mgmt_ip_vm1_0:
    type: string
    label: Management Network IPv4 Address
    description: Management Network IPv4 Address

resources:
  VDU1:
    type: OS::Heat::AutoScalingGroup
    properties:
      min_size: 1
      max_size: 3
      desired_capacity: 1
      resource:
        type: VDU1.yaml
        properties:
          flavor: { get_param: [ nfv, VDU, VDU1, flavor ] }
          image: { get_param: [ nfv, VDU, VirtualStorage, image ] }
          name: vdu1
          testnet: { get_resource: internalNW_1 }
          mgmt_ip_a: { get_param: mgmt_ip_vm0_0 }
          mgmt_ip_b: { get_param: mgmt_ip_vm1_0 }

The sample above shows the BaseHOT file getting the static IP from the request body using mgmt_ip_vm0_0 and mgmt_ip_vm1_0 parameters and assigned to mgmt_ip_a and mgmt_ip_b respectively.

The nested BaseHot file will then use the values acquired in the BaseHOT file to set the management IP of the resource.

parameters:
  flavor:
    type: string
  image:
    type: string
  name:
    type: string
  testnet:
    type: string
  mgmt_ip_a:
    type: string
    label: Management Network IPv4 Address
    description: Management Network IPv4 Address
  mgmt_ip_b:
    type: string
    label: Management Network IPv4 Address
    description: Management Network IPv4 Address

resources:
  VDU1:
    type: OS::Nova::Server
    properties:
      ...
  CP1:
    type: OS::Neutron::Port
    properties:
      network: { get_param: testnet }
      fixed_ips:
      - ip_address: { get_param:  mgmt_ip_a }

  CP2:
    type: OS::Neutron::Port
    properties:
      network: { get_param: testnet }
      fixed_ips:
      - ip_address: { get_param:  mgmt_ip_b }
  ...

The sample above shows the nested file of BaseHOT where the value of the IP address acquired from the BaseHOT file is being assigned to the port.

Set the static IP in the json request parameter for Instantiation under additionalParams.

{
    "flavourId": "default",
    ...
    "additionalParams": {
        "lcm-operation-user-data": "./UserData/lcm_user_data.py",
        "lcm-operation-user-data-class": "SampleUserData",
        "mgmt_ip_vm0_0": "10.1.1.20",
        "mgmt_ip_vm1_0": "10.1.1.24"
    }
}

Ordering Options

1. VDU Order

The order of VDU is based on the order keyword after config in the config.yaml file.

Sample:

vdus:
  VDU1:
    config:
      order: 1
      vm_app_config:
        ...

  VDU2:
    config:
      order: 0
      vm_app_config:
        ...

In the sample above, VDU2 is processed before VDU1 because of the value of the order.

Note

Should they have the same order, they will be executed randomly.

2. Command Order

The command order is necessary if you have multiple commands to be executed in a single configuration.

Sample:

vdus:
  VDU1:
    config:
      order: 1
      vm_app_config:
        type: ansible
        instantiation:
          - path: _VAR_vnf_package_path/Scripts/default/sample_start-1.yaml
            params:
              ansible_password: password
            order: 1
          - path: _VAR_vnf_package_path/Scripts/default/sample_start-2.yaml
            params:
              ansible_password: password
            order: 2
          - path: _VAR_vnf_package_path/Scripts/default/sample_start-3.yaml
            params:
              ansible_password: password
            order: 0
In the above example, the order of the command execution is as follows:
  • Scripts/default/sample_start-3.yaml

  • Scripts/default/sample_start-1.yaml

  • Scripts/default/sample_start-2.yaml

This is due to the order value of each commands.

Ansible Driver Usage

In case Ansible is not yet installed, please refer to the Ansible Installation Guide.

1. Copy Ansible Folder

First, copy the sample script that was stored in tacker/samples/mgmt_driver/ansible into the directory of tacker/tacker/vnfm/mgmt_drivers.

$ cp -pfr /opt/stack/tacker/samples/mgmt_driver/ansible /opt/stack/tacker/tacker/vnfm/mgmt_drivers/

Environment Configuration

1. Set the setup.cfg

You have to register ansible_driver in the operation environment of the tacker.

$ vi /opt/stack/tacker/setup.cfg
...
tacker.tacker.mgmt.drivers =
noop = tacker.vnfm.mgmt_drivers.noop:VnfMgmtNoop
openwrt = tacker.vnfm.mgmt_drivers.openwrt.openwrt:VnfMgmtOpenWRT
vnflcm_noop = tacker.vnfm.mgmt_drivers.vnflcm_noop:VnflcmMgmtNoop
ansible_driver = tacker.vnfm.mgmt_drivers.ansible.ansible:DeviceMgmtAnsible

2. Set the tacker.conf

Then find the vnflcm_mgmt_driver field in the tacker.conf. Add the ansible_driver defined in step 2 to it, and separate by commas.

$ vi /etc/tacker/tacker.conf
...
[tacker]
...
vnflcm_mgmt_driver = vnflcm_noop,ansible_driver
...

3. Update the tacker.egg-info

After the above two steps, the configuration has not yet taken effect. You also need to execute the setup.py script to regenerate the contents of the tacker.egg-info directory.

$ cd /opt/stack/tacker/
$ python setup.py build
running build
running build_py
running egg_info
writing requirements to tacker.egg-info/requires.txt
writing tacker.egg-info/PKG-INFO
writing top-level names to tacker.egg-info/top_level.txt
writing dependency_links to tacker.egg-info/dependency_links.txt
writing entry points to tacker.egg-info/entry_points.txt
writing pbr to tacker.egg-info/pbr.json
[pbr] Processing SOURCES.txt
[pbr] In git context, generating filelist from git
warning: no files found matching 'AUTHORS'
warning: no files found matching 'ChangeLog'
warning: no previously-included files matching '*.pyc' found anywhere in distribution
writing manifest file 'tacker.egg-info/SOURCES.txt'

Then you can use Mgmt Driver to deploy Ansible Driver after restarting the service of tacker and tacker-conductor.

$ sudo systemctl stop devstack@tacker
$ sudo systemctl restart devstack@tacker-conductor
$ sudo systemctl start devstack@tacker

VNF Package Creation

1. VNF Package Structure

The sample structure of VNF Package is shown below.

Note

You can also find them in the samples/mgmt_driver/ansible/ansible_vnf_package/ directory of the tacker.

The directory structure:

  • TOSCA-Metadata/TOSCA.meta

  • Definitions/

  • Files/images/

  • ScriptANSIBLE/

  • Scripts/

  • BaseHOT/

  • UserData/

!----TOSCA-Metadata
        !---- TOSCA.meta
!----Definitions
        !---- etsi_nfv_sol001_common_types.yaml
        !---- etsi_nfv_sol001_vnfd_types.yaml
        !---- helloworld3_top.vnfd.yaml
        !---- helloworld3_types.yaml
        !---- helloworld3_df_default.yaml
!----Files
        !---- images
                !---- cirros-0.5.2-x86_64-disk.img
!----ScriptANSIBLE
        !---- config.yaml
!----Scripts
        !---- default
                !---- sample.yaml
!----BaseHOT
        !---- default
                !---- nested
                        !---- VDU1.yaml
                !---- VNF-hot.yaml
!----UserData
        !---- __init__.py
        !---- lcm_user_data.py

2. ScriptANSIBLE

This directory contains the settings for running Ansible Script. This includes the path to the Ansible Playbook that each LCM runs, and the orders that should be executed according to each VDU, etc. It is mandatory to have a config.yaml file in this directory (as shown in the directory structure). This file is the one being parsed by the driver.

The configurable_properties in config.yaml file is a mandatory parameter. It can be used to define key-value pairs that can be used during VNF Configuration. The format of the key must start with _VAR_. So when the key is used in vm_app_config, then it will be replaced by the set value.

configurable_properties:
  _VAR_password: 'password'

vdus:
 VDU1:
   config:
     order: 1
     vm_app_config:
       type: ansible
       instantiation:
         - path: _VAR_vnf_package_path/Scripts/default/sample_start-1.yaml
           params:
             ansible_password: _VAR_password
           order: 0

The example above shows that we have a key _VAR_password with a value password. It will replace the _VAR_password used in the vm_app_config.

Note

The _VAR_vnf_package_path/ variable is mandatory for the path of the Ansible Playbook. This value is replaced by the actual vnf package path during runtime.

3. Scripts

This directory contains the user-defined Ansible Playbook to run on each LCM. The Playbook is executed based on the config.yaml definition under ScriptANSIBLE. The Sample Ansible Driver utilizes Ansible to run the Playbooks.

# This playbook prints a simple debug message
- name: Echo
  hosts: all
  remote_user: root

  tasks:
  - name: Creates a file
    remote_user: some_user
    become: yes
    become_method: sudo
    file:
      path:  "/tmp/sample.txt"
      state: touch

4. BaseHOT

Base HOT file is a Native cloud orchestration template, HOT in this context, which is commonly used for LCM operations in different VNFs. It is the responsibility of the user to prepare this file, and it is necessary to make it consistent with VNFD placed under the Definitions/ directory.

Here are the following that is needed to check in these files:
  • Under resources, there should be no _group in the name

heat_template_version: 2013-05-23
description: 'default deployment flavour for Sample VNF'

parameters:
  nfv:
    type: json

resources:
  VDU1:
    type: OS::Heat::AutoScalingGroup

All yaml files must have the outputs part. This is necessary in order to generate the mgmt_ip address. The format of the outputs part is as follows:

mgmt_ip-<VDU_NAME>:
  value:
    get_attr:
      - <VDU_CP>
      - fixed_ips
      - 0
      - ip_address

Example Ansible Driver LCM

1. VNF Package create/upload

Before you instantiate VNF, you must create a zip file of VNF Package and upload it.

Please refer to the procedure in Section Create and Upload VNF Package.

Note

Please do not forget the following folders to include in creating the zip file:

  • Files/

  • ScriptANSIBLE/

  • Scripts/

Please get the contents of the Files folder from the tacker/tests/etc/samples/etsi/nfv/common/Files/.

2. VNF Create/Instantiate

Please refer to the procedure in Section Create & Instantiate VNF.

Note

Please see the tacker-conductor.log for the Ansible Playbook Play results.

3. VNF Heal

Please refer to the procedure in Section VNF Healing.

Note

Please see the tacker-conductor.log for the Ansible Playbook Play results.

4. VNF Scale

Please refer to the procedure in Section VNF Scaling.

Note

Please see the tacker-conductor.log for the Ansible Playbook Play results.

5. VNF Terminate/Delete

Please refer to the procedure in Section Termination and Delete.

Note

Please see the tacker-conductor.log for the Ansible Playbook Play results.