openstack/tacker
Code Issues Proposed changes

Update documents for change in change-vnfpkg

Browse Source 
This patch updates Use Case Guide and API Documentation related to
Change Current VNF Package for Bobcat.
These updates include changes in the following patches.
* Fix missing modificationsTriggeredByVnfPkgChange [1]
* Add timeout setting to VNF LCM Coordination IF [2]

The main fixes in this patch are as follows.
* Add "vnflcm update" Use Case Guide for CNF
* Add how to update metadata/extensions/vnfConfigurableProperties
* Add note about extManagedVirtualLinks of ChangeCurrentVnfPkgRequest
* Add modificationTriggeredByVnfPkgChange to VnfLcmOpOcc
* Add timeout to additionalParams for ChangeCurrentVnfPkgRequest
* Add OAUTH2_CLIENT_CERT to authType
* Change vdu_params to required parameter

[1] https://review.opendev.org/c/openstack/tacker/+/880129
[2] https://review.opendev.org/c/openstack/tacker/+/887256

Closes-Bug: #2015941
Implements: blueprint add-sample-coordinate-script
Change-Id: I5a50ed88621ec7d2f82eb1f6d844d0ad5adae544
This commit is contained in:
Ai Hamano
2023-08-24 09:12:49 +09:00
parent a76871f8e6
commit 0cea1780ee
10 changed files with 619 additions and 451 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
api-ref/source/v2/parameters_vnflcm.yaml
View File

@@ -1062,6 +1062,48 @@ min_address:
in: body
required: true
type: string
modifications_triggered_by_vnf_pkg_change:
description: |
Information about performed changes of "VnfInstance" attributes
triggered by changing the current VNF package.
in: body
required: false
type: object
modifications_triggered_by_vnf_pkg_change_vnf_product_name:
description: |
If present, this attribute signals the new value of the
"vnfProductName" attribute in "VnfInstance".
in: body
required: false
type: string
modifications_triggered_by_vnf_pkg_change_vnf_provider:
description: |
If present, this attribute signals the new value of the
"vnfProvider" attribute in "VnfInstance".
in: body
required: false
type: string
modifications_triggered_by_vnf_pkg_change_vnf_software_version:
description: |
If present, this attribute signals the new value of the
"vnfSoftwareVersion" attribute in "VnfInstance".
in: body
required: false
type: string
modifications_triggered_by_vnf_pkg_change_vnfd_id:
description: |
If present, this attribute signals the new value of the
"vnfdId" attribute in "VnfInstance".
in: body
required: false
type: string
modifications_triggered_by_vnf_pkg_change_vnfd_version:
description: |
If present, this attribute signals the new value of the
"vnfdVersion" attribute in "VnfInstance".
in: body
required: false
type: string
monitoring_parameters:
description: |
Active monitoring parameters.

20
api-ref/source/v2/vnflcm.inc
View File

@@ -751,7 +751,7 @@ and are reflected in the representation of this resource.
According to the ETSI NFV SOL document, there is no API request/response
specification for Etag yet, and transactions using Etag are not defined
by standardization. Therefore, the Yoga release does not support
by standardization. Therefore, the Bobcat release does not support
`Error Code: 412 Precondition Failed`. Once a standard specification
for this is established, it will be installed on the tacker.
@@ -1106,6 +1106,15 @@ Response Parameters
- minAddress: min_address
- maxAddress: max_address
- subnetId: subnet_id
- modificationsTriggeredByVnfPkgChange: modifications_triggered_by_vnf_pkg_change
- vnfConfigurableProperties: changed_info_vnf_configurable_properties
- metadata: changed_info_metadata
- extensions: changed_info_extensions
- vnfdId: modifications_triggered_by_vnf_pkg_change_vnfd_id
- vnfProvider: modifications_triggered_by_vnf_pkg_change_vnf_provider
- vnfProductName: modifications_triggered_by_vnf_pkg_change_vnf_product_name
- vnfSoftwareVersion: modifications_triggered_by_vnf_pkg_change_vnf_software_version
- vnfdVersion: modifications_triggered_by_vnf_pkg_change_vnfd_version
- _links: vnf_instance_links
Response Example
@@ -1270,6 +1279,15 @@ Response Parameters
- minAddress: min_address
- maxAddress: max_address
- subnetId: subnet_id
- modificationsTriggeredByVnfPkgChange: modifications_triggered_by_vnf_pkg_change
- vnfConfigurableProperties: changed_info_vnf_configurable_properties
- metadata: changed_info_metadata
- extensions: changed_info_extensions
- vnfdId: modifications_triggered_by_vnf_pkg_change_vnfd_id
- vnfProvider: modifications_triggered_by_vnf_pkg_change_vnf_provider
- vnfProductName: modifications_triggered_by_vnf_pkg_change_vnf_product_name
- vnfSoftwareVersion: modifications_triggered_by_vnf_pkg_change_vnf_software_version
- vnfdVersion: modifications_triggered_by_vnf_pkg_change_vnfd_version
- _links: vnf_instance_links
Response Example

6
doc/source/cli/cli-etsi-vnflcm.rst
View File

@@ -24,12 +24,12 @@ CLI Reference for VNF Lifecycle Management
Commands with **\-\-os-tacker-api-version 2** call version 2 VNF LCM APIs.
.. note::
In Antelope release, version 2 VNF LCM APIs of Update
and Change External VNF Connectivity only support VNF, not CNF.
In Bobcat release, version 2 VNF LCM APIs of Change External VNF
Connectivity only support VNF, not CNF.
.. note::
Change Current VNF Package only support version 2 VNF LCM APIs.
In Antelope release, it only support ``RollingUpdate`` upgrade type,
In Bobcat release, it only support ``RollingUpdate`` upgrade type,
``BlueGreen`` will be supported in future releases.
1. Create VNF Identifier

267
doc/source/user/coordinate_api_client_in_coordinatevnf_script.rst
View File

@@ -52,8 +52,8 @@ If you want to know how to use `the Coordinate VNF script`,
please see the following documents of
ChangeCurrentVNFPackage API.
* `ETSI NFV-SOL VNF Change Current VNF Package`_.
* `ETSI NFV-SOL VNF Change Current VNF Package for StandardUserData`_.
* `ETSI NFV-SOL VNF Change Current VNF Package`_
* `ETSI NFV-SOL VNF Change Current VNF Package for StandardUserData`_
@@ -192,6 +192,10 @@ the VNF LCM Coordination API.
token, obtained using the client credentials
grant type after authenticating using client
identifier and client password.
* ``OAUTH2_CLIENT_CERT``: use an OAuth 2.0 token,
obtained using the client credentials grant type
after mutually authenticating using client
identifier and X.509 certificates.
* - \>>> paramsBasic
- 0..1
- Parameters for authentication/authorization
@@ -220,10 +224,39 @@ the VNF LCM Coordination API.
- 0..1
- The token endpoint from which the access token
can be obtained.
* - \>>> paramsOauth2ClientCert
- 0..1
- Parameters for authentication/authorization using
authType ``OAUTH2_CLIENT_CERT``.
* - >>>> clientId
- 1
- Client identifier to be used in the access token
request of the OAuth 2.0 client credentials
grant type.
* - >>>> certificateRef
- 1
- Fingerprint of the client certificate.
The hash function shall use SHA256 or higher.
* - >>>>> type
- 1
- The type of the fingerprint. Permitted values:
* ``x5t#S256``: The SHA-256 thumbprint of the X.509 certificate
as defined in section 4.1.8 of IETF RFC 7515.
* - >>>>> value
- 1
- The fingerprint value as defined by the type.
* - >>>> tokenEndpoint
- 1
- The token endpoint from which the access token
can be obtained.
* - >> coordination_server_param
- 0..1
- Information to access coordination server.
It is required when using coordinateVNF script which calling Coordination API.
* - >> timeout
- 0..1
- Timeout seconds for resending requests to Coordination API.
* - > new_vnfc_param
- 0..1
- New VNFC connection information.
@@ -256,6 +289,10 @@ the VNF LCM Coordination API.
token, obtained using the client credentials
grant type after authenticating using client
identifier and client password.
* ``OAUTH2_CLIENT_CERT``: use an OAuth 2.0 token,
obtained using the client credentials grant type
after mutually authenticating using client
identifier and X.509 certificates.
* - \>>> paramsBasic
- 0..1
- Parameters for authentication/authorization
@@ -284,10 +321,39 @@ the VNF LCM Coordination API.
- 0..1
- The token endpoint from which the access token
can be obtained.
* - \>>> paramsOauth2ClientCert
- 0..1
- Parameters for authentication/authorization using
authType ``OAUTH2_CLIENT_CERT``.
* - >>>> clientId
- 1
- Client identifier to be used in the access token
request of the OAuth 2.0 client credentials
grant type.
* - >>>> certificateRef
- 1
- Fingerprint of the client certificate.
The hash function shall use SHA256 or higher.
* - >>>>> type
- 1
- The type of the fingerprint. Permitted values:
* ``x5t#S256``: The SHA-256 thumbprint of the X.509 certificate
as defined in section 4.1.8 of IETF RFC 7515.
* - >>>>> value
- 1
- The fingerprint value as defined by the type.
* - >>>> tokenEndpoint
- 1
- The token endpoint from which the access token
can be obtained.
* - >> coordination_server_param
- 0..1
- Information to access coordination server.
It is required when using coordinateVNF script which calling Coordination API.
* - >> timeout
- 0..1
- Timeout seconds for resending requests to Coordination API.
* - external_lb_param
- 0..1
- Load balancer information that requires configuration changes.
@@ -306,71 +372,75 @@ the VNF LCM Coordination API.
.. code-block:: json
{
"additionalParams": {
"upgrade_type": "RollingUpdate",
"lcm-operation-coordinate-new-vnf": "./Scripts/coordinate_vnf.py",
"lcm-operation-coordinate-old-vnf": "./Scripts/coordinate_vnf.py",
"vdu_params": [{
"vdu_id": "VDU1",
"old_vnfc_param": {
"cp_name": "VDU1_CP1",
"username": "ubuntu",
"password": "ubuntu",
"endpoint": "http://127.0.0.1:6789",
"authentication": {
"authType": ["BASIC"],
"paramsBasic": {
"userName": "tacker",
"password": "tacker"
}
}
},
"new_vnfc_param": {
"cp_name": "VDU1_CP1",
"username": "ubuntu",
"password": "ubuntu",
"endpoint": "http://127.0.0.1:6789",
"authentication": {
"authType": ["BASIC"],
"paramsBasic": {
"userName": "tacker",
"password": "tacker"
}
}
}
},
{
"vdu_id": "VDU2",
"old_vnfc_param": {
"cp_name": "VDU2_CP1",
"username": "ubuntu",
"password": "ubuntu",
"endpoint": "http://127.0.0.1:6789",
"authentication": {
"authType": ["BASIC"],
"paramsBasic": {
"userName": "tacker",
"password": "tacker"
}
}
},
"new_vnfc_param": {
"cp_name": "VDU2_CP1",
"username": "ubuntu",
"password": "ubuntu",
"endpoint": "http://127.0.0.1:6789",
"authentication": {
"authType": ["BASIC"],
"paramsBasic": {
"userName": "tacker",
"password": "tacker"
}
}
}
}]
}
}
"additionalParams": {
"upgrade_type": "RollingUpdate",
"lcm-operation-coordinate-new-vnf": "./Scripts/coordinate_vnf.py",
"lcm-operation-coordinate-old-vnf": "./Scripts/coordinate_vnf.py",
"vdu_params": [
{
"vdu_id": "VDU1",
"old_vnfc_param": {
"cp_name": "VDU1_CP1",
"username": "ubuntu",
"password": "ubuntu",
"endpoint": "http://127.0.0.1:6789",
"authentication": {
"authType": ["BASIC"],
"paramsBasic": {
"userName": "tacker",
"password": "tacker"
}
},
"timeout": 30
},
"new_vnfc_param": {
"cp_name": "VDU1_CP1",
"username": "ubuntu",
"password": "ubuntu",
"endpoint": "http://127.0.0.1:6789",
"authentication": {
"authType": ["BASIC"],
"paramsBasic": {
"userName": "tacker",
"password": "tacker"
}
},
"timeout": 30
}
},
{
"vdu_id": "VDU2",
"old_vnfc_param": {
"cp_name": "VDU2_CP1",
"username": "ubuntu",
"password": "ubuntu",
"endpoint": "http://127.0.0.1:6789",
"authentication": {
"authType": ["BASIC"],
"paramsBasic": {
"userName": "tacker",
"password": "tacker"
}
},
"timeout": 30
},
"new_vnfc_param": {
"cp_name": "VDU2_CP1",
"username": "ubuntu",
"password": "ubuntu",
"endpoint": "http://127.0.0.1:6789",
"authentication": {
"authType": ["BASIC"],
"paramsBasic": {
"userName": "tacker",
"password": "tacker"
}
},
"timeout": 30
}
}
]
}
2. Request Change current VNF Package Process to InfraDriver
@@ -396,38 +466,45 @@ the VNF LCM Coordination API.
.. code-block:: console
class CoordScript(object):
def __init__(self, vnfc_param):
self.vnfc_param = vnfc_param
class CoordScript(object):
def __init__(self, vnfc_param):
self.vnfc_param = vnfc_param
def run(self):
if not os.path.exists('/tmp/change_vnfpkg_coordination'):
return
def run(self):
if not os.path.exists('/tmp/change_vnfpkg_coordination'):
return
coord_req = self.vnfc_param['LcmCoordRequest']
coord_req['coordinationActionName'] = (
"prv.tacker_organization.coordination_test")
endpoint = self.vnfc_param.get('endpoint')
authentication = self.vnfc_param.get('authentication')
coord_req = self.vnfc_param['LcmCoordRequest']
coord_req['coordinationActionName'] = (
"prv.tacker_organization.coordination_test")
endpoint = self.vnfc_param.get('endpoint')
authentication = self.vnfc_param.get('authentication')
timeout = self.vnfc_param.get('timeout')
input_params = self.vnfc_param.get('inputParams')
if input_params is not None:
coord_req['inputParams'] = input_params
input_params = self.vnfc_param.get('inputParams')
if input_params is not None:
coord_req['inputParams'] = input_params
if endpoint is None:
raise Exception('endpoint must be specified.')
if authentication is None:
raise Exception('authentication must be specified.')
if endpoint is None:
raise Exception('endpoint must be specified.')
if authentication is None:
raise Exception('authentication must be specified.')
coord = coord_client.create_coordination(endpoint, authentication,
coord_req)
if coord['coordinationResult'] != "CONTINUE":
raise Exception(
f"coordinationResult is {coord['coordinationResult']}")
# Reload "tacker.conf" when using OAUTH2_CLIENT_CERT
# for authentication.
args = ["--config-file", "/etc/tacker/tacker.conf"]
config.init(args)
def main():
script = CoordScript(vnfc_param)
script.run()
coord = coord_client.create_coordination(
endpoint, authentication, coord_req, timeout)
if coord['coordinationResult'] != "CONTINUE":
raise Exception(
f"coordinationResult is {coord['coordinationResult']}")
def main():
vnfc_param = pickle.load(sys.stdin.buffer)
script = CoordScript(vnfc_param)
script.run()
.. note::
According to ETSI-NFV SOL 002 v3.6.1, the coordination
@@ -472,6 +549,8 @@ the VNF LCM Coordination API.
Synchronous and Asynchronous modes.
API server decides the mode, and API client can know it by the API response.
Thus, since VNFM cannot control the mode, Tacker will support both modes.
In both modes, the timeout seconds for resending requests can be specified
with "timeout" in additionalParams.
The following shows the Coordination processes of VNFM.
|
| Synchronous mode: The EM returns to the Tacker a "201 Created" response
@@ -507,5 +586,3 @@ the VNF LCM Coordination API.
.. _ETSI NFV-SOL 002 v3.6.1: https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/03.06.01_60/gs_nfv-sol002v030601p.pdf
.. _ETSI NFV-SOL VNF Change Current VNF Package: https://docs.openstack.org/tacker/latest/user/etsi_vnf_change_current_vnf_package.html
.. _ETSI NFV-SOL VNF Change Current VNF Package for StandardUserData: https://docs.openstack.org/tacker/latest/user/etsi_vnf_change_current_vnf_package_with_standard_user_data.html
.. _VNF Package for Common instantiate: https://opendev.org/openstack/tacker/src/branch/master/tacker/tests/functional/sol_v2/samples/test_instantiate_vnf_with_old_image_or_volume/contents
.. _change from image to image: https://opendev.org/openstack/tacker/src/branch/master/tacker/tests/functional/sol_v2/samples/test_change_vnf_pkg_with_new_image/contents

307
doc/source/user/etsi_cnf_change_current_vnf_package.rst
View File

@@ -76,7 +76,7 @@ definition file before running command for changing the VNF package.
"upgrade_type": "RollingUpdate",
"lcm-kubernetes-def-files": ["Files/new_kubernetes/new_deployment.yaml"],
"vdu_params": [{
"vdu_id": "VDU1"
"vdu_id": "VDU2"
}]
},
"vimConnectionInfo": {
@@ -93,25 +93,20 @@ definition file before running command for changing the VNF package.
"dummy-key": "dummy-val"
}
}
}
}
``sample_param_file_without_specified_resources.json:``
.. code-block:: json
{
"vnfdId": "c6595341-a5bb-8246-53c4-7aeb843d60c5",
"additionalParams": {
"upgrade_type": "RollingUpdate",
},
"vnfConfigurableProperties": {
"key": "value"
},
"extensions": {
"key": "value"
}
}
.. note::
Unlike Change Current Vnf Package for VNF,
coordination scripts are not supported for CNF.
Therefore, lcm-operation-coordinate files need not be
specified by `additionalParams`.
Unlike Change Current Vnf Package for VNF,
coordination scripts are not supported for CNF.
Therefore, lcm-operation-coordinate files need not be
specified by ``additionalParams``.
You can set following parameter in additionalParams:
@@ -125,6 +120,9 @@ You can set following parameter in additionalParams:
* - upgrade_type
- 1
- Type of file update operation method. Specify Blue-Green or Rolling update.
* - lcm-kubernetes-def-files
- 0..N
- File path of the manifest file of the deployment resource.
* - vdu_params
- 1..N
- VDU information of target VDU to update.
@@ -132,41 +130,48 @@ You can set following parameter in additionalParams:
- 1
- VDU name of target VDU to update.
.. note:: ``sample_param_file_for_specified_resources.json`` contains
all optional parameters.
.. note::
``sample_param_file_for_specified_resources.json`` contains
all optional parameters.
* ``vnfdId`` is the vnfd id of the new VNF package you uploaded.
* ``lcm-kubernetes-def-files`` is only used in Kubernetes VIM, not
OpenStack VIM. And you only need to set this parameter when you need to
update the path of the manifest file of the deployment resource.
* ``vdu_params`` is VDU information of target VDU to update.
* ``vimConnectionInfo`` is an optional parameter.
This operation can specify the ``vimConnectionInfo`` for
the VNF instance.
Even if this operation specify multiple ``vimConnectionInfo``
associated with one VNF instance, only one of them will be used
for life cycle management operations.
It is not possible to delete the key of registered ``vimConnectionInfo``.
* ``vnfdId`` is the VNFD id of the new VNF package you uploaded.
* ``lcm-kubernetes-def-files`` is only used in Kubernetes VIM, not
OpenStack VIM. And you only need to set this parameter when you need to
update the path of the manifest file of the deployment resource.
* ``vimConnectionInfo`` is an optional parameter.
This operation can specify the ``vimConnectionInfo`` for
the VNF instance.
Even if this operation specify multiple ``vimConnectionInfo``
associated with one VNF instance, only one of them will be used
for life cycle management operations.
It is not possible to delete the key of registered ``vimConnectionInfo``.
* ``vnfConfigurableProperties`` and ``extensions`` are optional
parameter.
As with the update operation, these values are updated by performing
JSON Merge Patch with the values set in the request parameter to the
current values.
For ``metadata``, the value set before this operation is maintained.
.. note:: Currently, this operation only supports some functions of
``Change Current VNF Package``.
.. note::
Currently, this operation only supports some functions of
``Change Current VNF Package``.
* There are several ways to update deployment, but Yoga version Tacker only
supports ``RollingUpdate`` type. You can set it via ``upgrade_type``
param.
* There are several ways to update deployment, but Bobcat version Tacker only
supports ``RollingUpdate`` type. You can set it via ``upgrade_type``
param.
* Currently only support update images of deployment.
* Currently only support update images of deployment.
* Currently unsupported updates:
* Currently unsupported updates:
* This API currently does not support increasing or decreasing the number
of Pods according to the VNF package.
* The add and delete operations of the entire deployment are not
supported.
* In the definition of ETSI, external networks (e.g. extVirtualLinks,
extManagedVirtualLinks) can be modified. This API currently does not
support the operations of modifying, adding, and deleting these
networks.
* This API currently does not support increasing or decreasing the number
of Pods according to the VNF package.
* The add and delete operations of the entire deployment are not
supported.
* In the definition of ETSI, external networks (e.g. extVirtualLinks,
extManagedVirtualLinks) can be modified. This API currently does not
support the operations of modifying, adding, and deleting these
networks.
How to Change Current VNF Package with specified resource
@@ -264,7 +269,7 @@ Result:
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
vdu2-674d7d8766-8mcb6 1/1 Running 0 72s 10.233.96.15 node2 <none> <none>
vdu2-674d7d8766-tmlhd 1/1 Running 0 72s 10.233.96.14 node2 <none> <none
vdu2-674d7d8766-tmlhd 1/1 Running 0 72s 10.233.96.14 node2 <none> <none>
Change Current VNF Package execution of the entire VNF:
@@ -344,9 +349,10 @@ Result:
Normal ScalingReplicaSet 67s deployment-controller Scaled up replica set vdu2-6696c74f5c to 2
Normal ScalingReplicaSet 55s deployment-controller Scaled down replica set vdu2-674d7d8766 to 0
.. note:: ``image`` has changed from ``nginx`` to ``nginx:alpine``.
The age of deployment ``vdu2`` has not been reset, so deployment ``vdu2``
has not redeployed.
.. note::
``image`` has changed from ``nginx`` to ``nginx:alpine``.
The age of deployment ``vdu2`` has not been reset, so deployment ``vdu2``
has not redeployed.
Pods information after operation:
@@ -362,205 +368,10 @@ Result:
vdu2-6696c74f5c-9xwvv 1/1 Running 0 114s 10.233.96.17 node2 <none> <none>
vdu2-6696c74f5c-kgtjt 1/1 Running 0 2m5s 10.233.96.16 node2 <none> <none>
.. note:: ``name`` of pods has changed before and after operation.
The age of pods under deployment has been reset, so pods under
this deployment has redeployed before and after operation.
How to Change Current VNF Package without specified resource
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We can update all kubernetes deployment resources by not
specifying the file path of the kubernetes definition file in the
``lcm-kubernetes-def-files`` and vdu information in ``vdu_params``
of the ``change current VNF package`` request parameter file
(e.g. sample_param_file_without_specified_resources.json).
Execute Change Current VNF Package CLI command. After complete this change
operation you should check resource status by Kubernetes CLI commands.
1. check all deployments' image information. This is to confirm that
all deployments' images have changed before and after operation.
2. check the ages of deployments and pods under each deployment. This is to
confirm that the deployments have not redeployed before and after operation,
and the pods under each deployment have redeployed.
3. check the status and name of pods under this deployment. This is to confirm
that the status of pods under deployments are running, the names of pods
under deployments have changed before and after operation.
Deployments information before operation:
.. code-block:: console
$ kubectl get deployment -o wide
Result:
.. code-block:: console
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
vdu2 2/2 2 2 14s nginx nginx app=webserver
Deployment detailed information before operation:
.. code-block:: console
$ kubectl describe deployment vdu2
Result:
.. code-block:: console
Name: vdu2
Namespace: default
CreationTimestamp: Tue, 22 Mar 2022 05:38:12 +0000
Labels: <none>
Annotations: deployment.kubernetes.io/revision: 1
Selector: app=webserver
Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=webserver
Containers:
nginx:
Image: nginx
Port: 80/TCP
Host Port: 0/TCP
Limits:
memory: 200Mi
Requests:
memory: 100Mi
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: vdu2-674d7d8766 (2/2 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 73s deployment-controller Scaled up replica set vdu2-674d7d8766 to 2
Pods information before operation:
.. code-block:: console
$ kubectl get pods -o wide
Result:
.. code-block:: console
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
vdu2-674d7d8766-9bbnp 1/1 Running 0 2m13s 10.233.96.19 node2 <none> <none>
vdu2-674d7d8766-r9wz5 1/1 Running 0 2m13s 10.233.96.18 node2 <none> <none>
Change Current VNF Package execution of the entire VNF:
.. code-block:: console
$ openstack vnflcm change-vnfpkg VNF_INSTANCE_ID \
./sample_param_file_without_specified_resources.json \
--os-tacker-api-version 2
Result:
.. code-block:: console
Change Current VNF Package for VNF Instance 51dc9635-aaf0-4acf-b069-86017a39e2f4 has been accepted.
Deployments information after operation:
.. code-block:: console
$ kubectl get deployment -o wide
Result:
.. code-block:: console
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
vdu2 2/2 2 2 19m nginx nginx:alpine app=webserver
Deployment detailed information after operation:
.. code-block:: console
$ kubectl describe deployment vdu2
Result:
.. code-block:: console
Name: vdu2
Namespace: default
CreationTimestamp: Tue, 22 Mar 2022 05:38:12 +0000
Labels: <none>
Annotations: deployment.kubernetes.io/revision: 2
Selector: app=webserver
Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=webserver
Containers:
nginx:
Image: nginx:alpine
Port: 80/TCP
Host Port: 0/TCP
Limits:
memory: 200Mi
Requests:
memory: 100Mi
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: vdu2-6696c74f5c (2/2 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 20m deployment-controller Scaled up replica set vdu2-674d7d8766 to 2
Normal ScalingReplicaSet 15m deployment-controller Scaled up replica set vdu2-6696c74f5c to 1
Normal ScalingReplicaSet 14m deployment-controller Scaled down replica set vdu2-674d7d8766 to 1
Normal ScalingReplicaSet 14m deployment-controller Scaled up replica set vdu2-6696c74f5c to 2
Normal ScalingReplicaSet 14m deployment-controller Scaled down replica set vdu2-674d7d8766 to 0
.. note:: ``image`` has changed from ``nginx`` to ``nginx:alpine``.
The age of deployment ``vdu2`` has not been reset, so deployment ``vdu2``
has not redeployed.
Pods information after operation:
.. code-block:: console
$ kubectl get pods -o wide
Result:
.. code-block:: console
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
vdu2-6696c74f5c-cjdh8 1/1 Running 0 15m 10.233.96.21 node2 <none> <none>
vdu2-6696c74f5c-ssztd 1/1 Running 0 15m 10.233.96.20 node2 <none> <none>
.. note:: ``name`` of pods has changed before and after operation.
The age of pods under deployment has been reset, so pods under
this deployment has redeployed before and after operation.
.. note::
``name`` of pods has changed before and after operation.
The age of pods under deployment has been reset, so pods under
this deployment has redeployed before and after operation.
.. _VNF Package for Common instantiate: https://opendev.org/openstack/tacker/src/branch/master/tacker/tests/functional/sol_kubernetes_v2/samples/test_instantiate_cnf_resources/contents
.. _VNF Package for Change Current VNF Package: https://opendev.org/openstack/tacker/src/branch/master/tacker/tests/functional/sol_kubernetes_v2/samples/test_change_vnf_pkg_with_deployment/contents

151
doc/source/user/etsi_cnf_update.rst Normal file
View File

@@ -0,0 +1,151 @@
=======================
ETSI NFV-SOL CNF Update
=======================
This document describes how to update CNF in Tacker.
Please refer to the :doc:`./mgmt_driver_for_container_update`
for how to update CNF with Mgmt Driver in Tacker.
Prerequisites
-------------
The following packages should be installed:
* tacker
* python-tackerclient
The procedure of prepare for scaling operation that from "register VIM" to
"Instantiate VNF", basically refer to
:doc:`./etsi_containerized_vnf_usage_guide`.
This procedure uses an example using the sample VNF package.
CNF Update Procedures
---------------------
As mentioned in Prerequisites, the CNF must be created
before performing update.
Details of CLI commands are described in
:doc:`../cli/cli-etsi-vnflcm`.
For update VNF instance, you need to prepare a JSON-formatted definition file.
.. code-block:: json
{
"vnfInstanceName": "sample"
}
.. note::
sample_param_file.json contains the VNF name as an example.
For v1 update operation, the following attributes of
``VnfInfoModificationRequest`` are not supported.
* vnfConfigurableProperties
* metadata
* extensions
* vnfcInfoModifications
* vimConnectionInfo
.. note::
The v2 update operation can change the ``vimConnectionInfo``
associated with an existing VNF instance.
Even if update operation specify multiple ``vimConnectionInfo``
associated with one VNF instance, only one of them will be used for life
cycle management operations.
It is not possible to delete the key of registered ``vimConnectionInfo``.
How to Update CNF
~~~~~~~~~~~~~~~~~
Execute Update CLI command and check the name of VNF instance before
and after update. This is to confirm that the name of VNF instance has
changed after update.
VNF instance name before update:
.. code-block:: console
$ openstack vnflcm show VNF_INSTANCE_ID -c 'VNF Instance Name'
Result:
.. code-block:: console
+-------------------+-------+
| Field | Value |
+-------------------+-------+
| VNF Instance Name | None |
+-------------------+-------+
Update VNF can be executed by the following CLI command.
.. code-block:: console
$ openstack vnflcm update VNF_INSTANCE_ID --I sample_param_file.json
Result:
.. code-block:: console
Update vnf:c64ea0fd-a90c-4754-95f4-dc0751db519d
.. note::
Create a parameter file that describes the resource information to be
changed in advance.
VNF instance name after operation:
.. code-block:: console
$ openstack vnflcm show VNF_INSTANCE_ID -c 'VNF Instance Name'
Result:
.. code-block:: console
+-------------------+---------+
| Field | Value |
+-------------------+---------+
| VNF Instance Name | sample |
+-------------------+---------+
You can confirm that the VNF Instance Name has been changed by the update
operation.
If the ``vnfdId`` is not changed by update operation, the current value
shall be updated using the request parameter.
The following attributes are updated by performing JSON Merge Patch with the
values set in the request parameter to the current values.
* vnfConfigurableProperties
* metadata
* extensions
If the ``vnfdId`` is requested to be changed by v1 update operation, the
following attributes of VNF instance shall be updated in addition to those
set in the request parameters.
These are updated with the values obtained from the VNFD associated with the
new vnfdId.
* vnfProvider
* vnfProductName
* vnfSoftwareVersion
* vnfdVersion
.. note::
In the v2 update operation for CNF, if "Scale" or "Heal" is performed
after updating ``vnfdId``, the VNF package associated with the
``vnfdId before the update`` shall be used.
Therefore, in order to maintain the update of ``vnfdId``, it is necessary to
execute "Terminate VNF" once and then "Instantiate VNF".

8
doc/source/user/etsi_use_case_guide.rst
View File

@@ -76,6 +76,14 @@ VM
etsi_vnf_update
Container
~~~~~~~~~
.. toctree::
:maxdepth: 1
etsi_cnf_update
Change External VNF Connectivity
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

170
doc/source/user/etsi_vnf_change_current_vnf_package.rst
View File

@@ -46,18 +46,18 @@ VNF package.
.. note::
You can deploy a VM directly by image or volume.
Therefore, when updating the
image of the VM, there will be two cases.
You can deploy a VM directly by image or volume.
Therefore, when updating the
image of the VM, there will be two cases.
Use the common VNF package and the flavor_id to instantiate,
and then use the VNF package in the corresponding link to
execute ``change current vnf package`` operation,
you can update the image of the VM in the following two ways.
Use the common VNF package and the flavor_id to instantiate,
and then use the VNF package in the corresponding link to
execute ``change current vnf package`` operation,
you can update the image of the VM in the following two ways.
1. change VM created by image to VM created by new image
1. change VM created by image to VM created by new image
2. change VM created by volume to VM created by new volume
2. change VM created by volume to VM created by new volume
Change Current VNF Package
--------------------------
@@ -129,6 +129,12 @@ definition file before running command for changing the VNF package.
"vimId": "defb2f96-5670-4bef-8036-27bf61267fc1",
"vimType": "ETSINFV.OPENSTACK_KEYSTONE.V_3"
}
},
"vnfConfigurableProperties": {
"key": "value"
},
"extensions": {
"key": "value"
}
}
@@ -171,21 +177,21 @@ You can set following parameter in additionalParams:
- 1
- Type of file update operation method. Specify Blue-Green or Rolling update.
* - lcm-operation-coordinate-old-vnf
- 1
- 0..1
- The file path of the script that simulates the behavior of CoordinateVNF for old VNF.
* - lcm-operation-coordinate-new-vnf
- 1
- 0..1
- The file path of the script that simulates the behavior of CoordinateVNF for new VNF.
* - vdu_params
- 0..N
- VDU information of target VDU to update. Specifying a vdu_params is required for OpenStack VIM and not required for Kubernetes VIM.
- 1..N
- VDU information of target VDU to update.
* - > vdu_id
- 1
- VDU name of target VDU to update.
* - > old_vnfc_param
- 0..1
- Old VNFC connection information. Required for ssh connection in CoordinateVNF operation for application configuration to VNFC.
* - >> cp-name
* - >> cp_name
- 1
- Connection point name of old VNFC to update.
* - >> username
@@ -197,7 +203,7 @@ You can set following parameter in additionalParams:
* - > new_vnfc_param
- 0..1
- New VNFC connection information. Required for ssh connection in CoordinateVNF operation for application configuration to VNFC.
* - >> cp-name
* - >> cp_name
- 1
- Connection point name of new VNFC to update.
* - >> username
@@ -218,48 +224,62 @@ You can set following parameter in additionalParams:
* - > password
- 1
- Password of load balancer server.
* - lcm-operation-user-data
- 0..1
- File name of UserData to use.
* - lcm-operation-user-data-class
- 0..1
- Class name of UserData to use.
.. note:: ``sample_param_file_for_multi_resources.json`` contains all optional
parameters. It can be used to change image for both VDU created by
``OS::Heat::AutoScalingGroup`` and single VDU.
``sample_param_file_for_single_resource.json`` only used to change image for
single VDU.
.. note::
``sample_param_file_for_multi_resources.json`` contains all optional
parameters. It can be used to change image for both VDU created by
``OS::Heat::AutoScalingGroup`` and single VDU.
``sample_param_file_for_single_resource.json`` only used to change image for
single VDU.
* ``vnfdId`` is the vnfd id of the new VNF package you uploaded.
* ``lcm-operation-coordinate-old-vnf`` and
``lcm-operation-coordinate-new-vnf`` are unique implementations of Tacker
to simulate the coordination interface in `ETSI SOL002 v3.5.1`_. Mainly a
script that can communicate with the VM after the VM is created, perform
special customization of the VM or confirm the status of the VM.
* ``vimConnectionInfo`` is an optional parameter.
This operation can specify the ``vimConnectionInfo`` for
the VNF instance.
Even if this operation specify multiple ``vimConnectionInfo``
associated with one VNF instance, only one of them will be used
for life cycle management operations.
It is not possible to delete the key of registered ``vimConnectionInfo``.
* ``vnfdId`` is the VNFD id of the new VNF package you uploaded.
* ``lcm-operation-coordinate-old-vnf`` and
``lcm-operation-coordinate-new-vnf`` are unique implementations of Tacker
to simulate the coordination interface in `ETSI SOL002 v3.5.1`_. Mainly a
script that can communicate with the VM after the VM is created, perform
special customization of the VM or confirm the status of the VM.
* ``vimConnectionInfo`` is an optional parameter.
This operation can specify the ``vimConnectionInfo`` for
the VNF instance.
Even if this operation specify multiple ``vimConnectionInfo``
associated with one VNF instance, only one of them will be used
for life cycle management operations.
It is not possible to delete the key of registered ``vimConnectionInfo``.
* ``vnfConfigurableProperties`` and ``extensions`` are optional
parameter.
As with the update operation, these values are updated by performing
JSON Merge Patch with the values set in the request parameter to the
current values.
For ``metadata``, the value set before this operation is maintained.
.. note:: Currently, this operation only supports some functions of
``Change Current VNF Package``.
.. note::
Currently, this operation only supports some functions of
``Change Current VNF Package``.
* There are several ways to update VDUs, but Yoga version Tacker only
supports ``RollingUpdate`` type. You can set it via ``upgrade_type``
param.
* There are several ways to update VDUs, but Bobcat version Tacker only
supports ``RollingUpdate`` type. You can set it via ``upgrade_type``
param.
* Currently only support update images of VMs and modify external networks..
* Currently only support update images of VMs and modify external networks.
* Currently unsupported updates:
* Currently unsupported updates:
* This API currently does not support increasing or decreasing the number
of VNFcs according to the VNF package.
* The add and delete operations of the entire VDU are not supported.
* In the definition of ETSI, external and internal networks
(e.g. extVirtualLinks, extManagedVirtualLinks) can be modified.
This current API supports the operations of modifying external
networks only and does not support the following operations.
* This API currently does not support increasing or decreasing the number
of VNFcs according to the VNF package.
* The add and delete operations of the entire VDU are not supported.
* In the definition of ETSI, external and internal networks
(e.g. extVirtualLinks, extManagedVirtualLinks) can be modified.
This current API supports the operations of modifying external
networks only and does not support the following operations.
* Adding and deleting external networks.
* Modifying, adding, and deleting internal networks.
* Adding and deleting external networks.
* Modifying, adding, and deleting internal networks.
How to Change VM created by image to VM created by new image
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -281,10 +301,10 @@ confirm that VDU's has changed successfully.
See `Heat CLI reference`_. for details on Heat CLI commands.
.. note::
Both single VM and VM created by ``OS::Heat::AutoScalingGroup`` support
change from image to image.
The single VM is created directly by ``OS::Nova::Server`` defined in the
top heat template.
Both single VM and VM created by ``OS::Heat::AutoScalingGroup`` support
change from image to image.
The single VM is created directly by ``OS::Nova::Server`` defined in the
top heat template.
* Check point 1 before operation
@@ -465,7 +485,7 @@ See `Heat CLI reference`_. for details on Heat CLI commands.
| 5330ea82-0fd6-4a29-a796-0646e7c6815f | vnf-7f8e5afa-101e-4e0b-a936-62fe01ef1b25 | UPDATE_COMPLETE |
+--------------------------------------+------------------------------------------+-----------------+
.. note::
'Stack Status' transitions to UPDATE_COMPLETE.
'Stack Status' transitions to UPDATE_COMPLETE.
* Check point 2 after operation
@@ -503,7 +523,7 @@ See `Heat CLI reference`_. for details on Heat CLI commands.
| xgaeg5oul435 | f96d0234-1486-47e4-8fd5-ec986e46c01e | base_hot_nested_VDU1.yaml | UPDATE_COMPLETE | 2022-03-16T07:14:19Z |
+---------------+--------------------------------------+---------------------------+-----------------+----------------------+
.. note::
'resource_status' transitions to UPDATE_COMPLETE.
'resource_status' transitions to UPDATE_COMPLETE.
VDU(created by ``OS::Heat::AutoScalingGroup``) information after operation:
@@ -521,8 +541,9 @@ See `Heat CLI reference`_. for details on Heat CLI commands.
| VDU1 | 0810da4d-3466-4852-aa92-60ad05027b5a | OS::Nova::Server | UPDATE_COMPLETE | 2022-03-16T07:13:32Z |
| VDU1_CP1 | 0bb0a091-b53f-484c-8050-77a44c2537f6 | OS::Neutron::Port | CREATE_COMPLETE | 2022-03-16T07:02:52Z |
+---------------+--------------------------------------+-------------------+-----------------+----------------------+
.. note::
'resource_status' transitions to UPDATE_COMPLETE.
'resource_status' transitions to UPDATE_COMPLETE.
VDU(single) information after operation:
@@ -568,7 +589,8 @@ See `Heat CLI reference`_. for details on Heat CLI commands.
| | ATTR:ramdisk_id': '', 'OS-EXT-SRV-ATTR:root_device_name': '/dev/vda', 'OS-EXT-SRV-ATTR:user_data': '...' |
+------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
.. note:: You can check 'image'->'id' has changed from
.. note::
You can check 'image'->'id' has changed from
'3f87132d-0c98-42a6-aa7b-b7db1f25e4fa' to
'68da152a-13af-43f6-aaaa-a7b88123d654'.
@@ -597,7 +619,8 @@ See `Heat CLI reference`_. for details on Heat CLI commands.
| | ATTR:kernel_id': '', 'OS-EXT-SRV-ATTR:ramdisk_id': '', 'OS-EXT-SRV-ATTR:root_device_name': '/dev/vda', 'OS-EXT-SRV-ATTR:user_data': '...' |
+------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
.. note:: You can check 'image'->'id' has changed from
.. note::
You can check 'image'->'id' has changed from
'3f87132d-0c98-42a6-aa7b-b7db1f25e4fa' to
'18fd7e66-c81f-48bb-bf18-d523996ce59c'.
@@ -621,8 +644,9 @@ VDU's parent resource has been updated successfully,
3. check 'volume' information of VDU before and after operation. This is to
confirm that VDU's has changed successfully.
.. note:: Both single VM and VM created by ``OS::Heat::AutoScalingGroup`` support
change from image to image.
.. note::
Both single VM and VM created by ``OS::Heat::AutoScalingGroup`` support
change from image to image.
* Check point 1 before operation
@@ -809,7 +833,7 @@ confirm that VDU's has changed successfully.
+--------------------------------------+------------------------------------------+-----------------+
.. note::
'Stack Status' transitions to UPDATE_COMPLETE.
'Stack Status' transitions to UPDATE_COMPLETE.
* Check point 2 after operation
@@ -848,7 +872,7 @@ confirm that VDU's has changed successfully.
+---------------+--------------------------------------+---------------------------+-----------------+----------------------+
.. note::
'resource_status' transitions to UPDATE_COMPLETE.
'resource_status' transitions to UPDATE_COMPLETE.
VDU(created by ``OS::Heat::AutoScalingGroup``) information after operation:
@@ -870,10 +894,10 @@ confirm that VDU's has changed successfully.
+---------------------+--------------------------------------+------------------------+-----------------+----------------------+
.. note::
'resource_status' transitions to CREATE_COMPLETE.
'physical_resource_id' changes from
'3f3fa0d8-b948-45fe-bd86-41d5d3e28974' to
'7d19f797-eb11-4af5-ba3b-d35349136786'.
'resource_status' transitions to CREATE_COMPLETE.
'physical_resource_id' changes from
'3f3fa0d8-b948-45fe-bd86-41d5d3e28974' to
'7d19f797-eb11-4af5-ba3b-d35349136786'.
VDU(single) information after operation:
@@ -898,10 +922,10 @@ confirm that VDU's has changed successfully.
+---------------------+--------------------------------------+----------------------------+-----------------+----------------------+
.. note::
'resource_status' transitions to CREATE_COMPLETE.
'physical_resource_id' changes from
'23122c2d-d51d-422a-8ad6-6c3625c761b6' to
'9aeae773-0f5b-4809-a83b-dee09214db90'.
'resource_status' transitions to CREATE_COMPLETE.
'physical_resource_id' changes from
'23122c2d-d51d-422a-8ad6-6c3625c761b6' to
'9aeae773-0f5b-4809-a83b-dee09214db90'.
* Check point 3 after operation
@@ -932,7 +956,8 @@ confirm that VDU's has changed successfully.
| | 'locked_reason': None, 'description': None, 'tags': [], 'trusted_image_certificates': None, 'server_groups': [], 'os_collect_config': {}} |
+------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
.. note:: You can check 'os-extended-volumes:volumes_attached'->'id'
.. note::
You can check 'os-extended-volumes:volumes_attached'->'id'
has changed from '68a53b24-83eb-4e88-a605-1e9d922e3ec0' to
'21f9aa89-4456-42a6-8888-f08c8f70933f'.
@@ -961,7 +986,8 @@ confirm that VDU's has changed successfully.
| | 'host_status': 'UP', 'locked': False, 'locked_reason': None, 'description': None, 'tags': [], 'trusted_image_certificates': None, 'server_groups': [], 'os_collect_config': {}} |
+------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
.. note:: You can check 'os-extended-volumes:volumes_attached'->'id' has
.. note::
You can check 'os-extended-volumes:volumes_attached'->'id' has
changed from '68a53b24-83eb-4e88-a605-1e9d922e3ec0' to
'fc0e0fcf-8eb9-4ddc-8194-2df6c1b43a7b'.

37
doc/source/user/etsi_vnf_change_current_vnf_package_with_standard_user_data.rst
View File

@@ -72,7 +72,7 @@ before performing change current VNF package.
Currently, this operation only supports some functions of
``Change Current VNF Package``.
* There are several ways to update VDUs, but in the Antelope version
* There are several ways to update VDUs, but in the Bobcat version
Tacker only supports ``RollingUpdate`` type.
You can set it via ``upgrade_type`` param.
@@ -212,11 +212,21 @@ definition file before running command.
"vimId": "defb2f96-5670-4bef-8036-27bf61267fc1",
"vimType": "ETSINFV.OPENSTACK_KEYSTONE.V_3"
}
},
"vnfConfigurableProperties": {
"key": "value"
},
"extensions": {
"key": "value"
}
}
.. note::
* ``vnfdId`` is the vnfd id of the new VNF package you uploaded.
* ``vnfdId`` is the VNFD id of the new VNF package you uploaded.
* ``extManagedVirtualLinks`` is an optional parameter.
Note that if the VNF Instance uses ``extManagedVirtualLinkInfo``,
``extManagedVirtualLinks`` needs to be set in the request
parameters regardless of whether it is changed.
* ``lcm-operation-coordinate-old-vnf`` and
``lcm-operation-coordinate-new-vnf`` are unique implementations of
Tacker to simulate the coordination interface in
@@ -232,6 +242,12 @@ definition file before running command.
life cycle management operations.
It is not possible to delete the key of registered
``vimConnectionInfo``.
* ``vnfConfigurableProperties`` and ``extensions`` are optional
parameter.
As with the update operation, these values are updated by performing
JSON Merge Patch with the values set in the request parameter to the
current values.
For ``metadata``, the value set before this operation is maintained.
You can set following parameter in additionalParams:
@@ -247,17 +263,16 @@ You can set following parameter in additionalParams:
- Type of file update operation method. Specify Blue-Green or
Rolling update.
* - lcm-operation-coordinate-old-vnf
- 1
- 0..1
- The file path of the script that simulates the behavior of
CoordinateVNF for old VNF.
* - lcm-operation-coordinate-new-vnf
- 1
- 0..1
- The file path of the script that simulates the behavior of
CoordinateVNF for new VNF.
* - vdu_params
- 0..N
- VDU information of target VDU to update. Specifying a vdu_params
is required for OpenStack VIM and not required for Kubernetes VIM.
- 1..N
- VDU information of target VDU to update.
* - > vdu_id
- 1
- VDU name of target VDU to update.
@@ -265,7 +280,7 @@ You can set following parameter in additionalParams:
- 0..1
- Old VNFC connection information. Required for ssh connection in
CoordinateVNF operation for application configuration to VNFC.
* - >> cp-name
* - >> cp_name
- 1
- Connection point name of old VNFC to update.
* - >> username
@@ -278,7 +293,7 @@ You can set following parameter in additionalParams:
- 0..1
- New VNFC connection information. Required for ssh connection in
CoordinateVNF operation for application configuration to VNFC.
* - >> cp-name
* - >> cp_name
- 1
- Connection point name of new VNFC to update.
* - >> username
@@ -302,10 +317,10 @@ You can set following parameter in additionalParams:
- 1
- Password of load balancer server.
* - lcm-operation-user-data
- 0..1
- 1
- File name of UserData to use.
* - lcm-operation-user-data-class
- 0..1
- 1
- Class name of UserData to use.
.. note::

62
doc/source/user/etsi_vnf_update.rst
View File

@@ -39,7 +39,24 @@ For update VNF instance, you need to prepare a JSON-formatted definition file.
"vnfInstanceName": "sample"
}
.. note:: sample_param_file.json contains the VNF name as an example.
.. note::
sample_param_file.json contains the VNF name as an example.
For v1 update operation, the following attributes of
``VnfInfoModificationRequest`` are not supported.
* vnfConfigurableProperties
* metadata
* extensions
* vnfcInfoModifications
* vimConnectionInfo
.. note::
The v2 update operation can change the ``vimConnectionInfo``
associated with an existing VNF instance.
Even if update operation specify multiple ``vimConnectionInfo``
associated with one VNF instance, only one of them will be used for life
cycle management operations.
It is not possible to delete the key of registered ``vimConnectionInfo``.
How to Update VNF
@@ -85,24 +102,6 @@ Result:
Create a parameter file that describes the resource information to be
changed in advance.
.. note::
If the *vnfdId* is not changed by update operation, the current value
shall be updated using the request parameter.
If the *vnfdId* is requested to be changed by update operation, the
current values of *metadata*, *extension*, and *vnfConfigurableProperties*
are cleared and the changed request parameters are applied.
Current Tacker only refers *metadata*, *extension* and
*vnfConfigurableProperties* specified in the API request. It means that
Tacker does not refer the value of these parameters specified in VNFD.
.. note::
The update operation can change the ``vimConnectionInfo``
associated with an existing VNF instance.
Even if update operation specify multiple ``vimConnectionInfo``
associated with one VNF instance, only one of them will be used for life
cycle management operations.
It is not possible to delete the key of registered ``vimConnectionInfo``.
VNF instance name after operation:
@@ -122,8 +121,29 @@ Result:
+-------------------+---------+
You can confirm that the VNF Instance Name has been changed
by the update operation.
You can confirm that the VNF Instance Name has been changed by the update
operation.
If the ``vnfdId`` is not changed by update operation, the current value
shall be updated using the request parameter.
The following attributes are updated by performing JSON Merge Patch with the
values set in the request parameter to the current values.
* vnfConfigurableProperties
* metadata
* extensions
If the ``vnfdId`` is requested to be changed by v1 update operation, the
following attributes of VNF instance shall be updated in addition to those
set in the request parameters.
These are updated with the values obtained from the VNFD associated with the
new vnfdId.
* vnfProvider
* vnfProductName
* vnfSoftwareVersion
* vnfdVersion
.. _Heat CLI reference : https://docs.openstack.org/python-openstackclient/latest/cli/plugin-commands/heat.html