Merge branch 'feauture_10908_ns_update' into 'master'

osm ns-list

```

## Updating the VNF instance in a Network Service

If you have an active network service and you would like to update the one of your running VNF instances, you can follow the below steps in order to update it.

### Update the VNF package

To be able update the NS instance, first we need to create a new revision of the VNFd package that has the changes we want to perform in our NS. The existing VNFD can be updated by executing the following command through the CLI.

```bash

osm vnfpkg-update --content  <new_vnfd_package>  <vnfd_package_name_to_be_updated> 

```

Example:

```bash

osm vnfpkg-update --content  ha_proxy_charm_vnf  ha_proxy_charm-vnf 

```

You can modify your VNFD according to the update type you would like to apply.

There are 2 supported update types:

- CHANGE_VNFPKG

- REMOVE_VNF

#### CHANGE_VNFPKG Update

CHANGE_VNFPKG update type provides following operations on a running VNF instance:

- Redeploy the VNF

- Upgrade the charms in the VNF

- Update the policies

##### Alterable parameters in VNFD for redeployment

There is a distinctive parameter named `software-version` in VNF descriptor which is used to dissociate the CHANGE_VNFPKG update type operations.

If the updated package `software-version` has changed and the original VNFD does not include a charm, the VNF is redeployed (the redeployment is only available right now for NFs that don't include charms).

If the `software-version` is not placed in the VNFD, it is taken as 1.0 by default.

At that time, most of the parameters could be changed in the modified VNF package except the parameters which are refered in NSD.

```yaml

vnfd:

  id: ha_proxy_charm-vnf

  mgmt-cp: vnf-mgmt-ext

  product-name: ha_proxy_charm-vnf

  description: A VNF consisting of 1 VDU

    data and another one for management

  version: 1.0

  software-version: 1.0

```

##### Alterable parameters in VNFD for charm upgrade in the VNF Instance

The charm upgrade in a running VNF instance is supported unless the running VNF is a juju-bundle.

Only the parameter changes of day1-2 operations are allowed for charm upgrade operations.

Here are the alterable parameters in the VNFD for charm upgrade operations:

All day1-2:initial-config-primitives are allowed to change.

```yaml

    |  +--rw lcm-operations-configuration

    |  |  +--rw operate-vnf-op-config    

    |  |  |     +--rw day1-2:initial-config-primitive* [seq]

    |  |  |     |  +--rw day1-2:seq                                uint64

    |  |  |     |  +--rw (day1-2:primitive-type)?

    |  |  |     |     +--:(day1-2:primitive-definition)

    |  |  |     |        +--rw day1-2:name?                        string

    |  |  |     |        +--rw day1-2:execution-environment-ref?   -> ../../execution-environment-list/id

    |  |  |     |        +--rw day1-2:parameter* [name]

    |  |  |     |        |  +--rw day1-2:name         string

    |  |  |     |        |  +--rw day1-2:data-type?   common:parameter-data-type

    |  |  |     |        |  +--rw day1-2:value?       string

    |  |  |     |        +--rw day1-2:user-defined-script?         string

```

All day1-2:config-primitives are allowed to change.

```yaml

    |  +--rw lcm-operations-configuration

    |  |  +--rw operate-vnf-op-config

    |  |  |     +--rw day1-2:config-primitive* [name]

    |  |  |     |  +--rw day1-2:name                               string

    |  |  |     |  +--rw day1-2:execution-environment-ref?         -> ../../execution-environment-list/id

    |  |  |     |  +--rw day1-2:execution-environment-primitive?   string

    |  |  |     |  +--rw day1-2:parameter* [name]

    |  |  |     |  |  +--rw day1-2:name              string

    |  |  |     |  |  +--rw day1-2:data-type?        common:parameter-data-type

    |  |  |     |  |  +--rw day1-2:mandatory?        boolean

    |  |  |     |  |  +--rw day1-2:default-value?    string

    |  |  |     |  |  +--rw day1-2:parameter-pool?   string

    |  |  |     |  |  +--rw day1-2:read-only?        boolean

    |  |  |     |  |  +--rw day1-2:hidden?           boolean

    |  |  |     |  +--rw day1-2:user-defined-script?               string

```

All day1-2:terminate-config-primitives are allowed to change.

```yaml

    |  +--rw lcm-operations-configuration

    |  |  +--rw operate-vnf-op-config

    |  |  |     +--rw day1-2:terminate-config-primitive* [seq]

    |  |  |     |  +--rw day1-2:seq                          uint64

    |  |  |     |  +--rw day1-2:name?                        string

    |  |  |     |  +--rw day1-2:execution-environment-ref?   -> ../../execution-environment-list/id

    |  |  |     |  +--rw day1-2:parameter* [name]

    |  |  |     |  |  +--rw day1-2:name         string

    |  |  |     |  |  +--rw day1-2:data-type?   common:parameter-data-type

    |  |  |     |  |  +--rw day1-2:value?       string

    |  |  |     |  +--rw day1-2:user-defined-script?         string

```

##### Alterable parameters for policy updates

Policy update changes are performed on running VNF instance unless `software-version` is changed in the new revision of VNFD.

TODO: write the alterable parameters

#### REMOVE_VNF Update

TODO: write the details

### Perform NS Update Operation

In the ns update request, all the parameters are mandatory except the timeout and wait parameters.

Update request is executed per VNF basis. VnfdId in the update request should be same with the vnfd-id of VNF to be updated.

VNF is always updated to the latest VNFD revision although there are several VNFD revisions. Updating VNF by using specific VNFD revision is not supported at the moment.

300 or higher float variables are supported as timeout parameter.

update_type has 2 options:

- CHANGE_VNFPKG

- REMOVE_VNF

If CHANGE_VNFPKG is selected as update_type, update_data is changeVnfPackageData

If REMOVE_VNF is selected as update_type, update_data is removeVnfInstanceId

```bash

osm ns-update  <ns_instance_id> --updatetype <update_type> --config '{<update_data>: [{vnfInstanceId: <vnf_instance_id>, vnfdId: <vnfd_id>}]}' --timeout 300 --wait

```

Example command:

```bash

osm ns-update  6f0835ba-50cb-4e69-b745-022ea2319b96 --updatetype CHANGE_VNFPKG --config '{changeVnfPackageData: [{vnfInstanceId: "f13dfde9-b7da-4469-a921-1a66923f084c", vnfdId: "7f30ca8b-2c96-4bd3-8eab-b7eb19c2a9ed"}]}' --timeout 300 --wait

```

## Advanced instantiation: using instantiation parameters

OSM allows the parametrization of NS or NSI upon instantiation (Day-0 and Day-1), so that the user can easily decide on the key parameters of the service without any need of changing the original set of validated packages.