diff --git a/05-osm-usage.md b/05-osm-usage.md index dd05328a93d2db19cc1ffa7f698a9a0d27c18d6f..23977b266133333720121cec8c87042a5545ace1 100644 --- a/05-osm-usage.md +++ b/05-osm-usage.md @@ -78,6 +78,161 @@ osm ns-create --ns_name --nsd_name hackfest_basic-ns --vim_ac 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 +``` + +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 --updatetype --config '{: [{vnfInstanceId: , vnfdId: }]}' --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.