Wallaby Series Release Notes¶
5.0.0¶
Prelude¶
This release contains a new feature to attach an already created or existing volume with VNF. Enhancement to an existing feature that supports attachment of persistent volumes to VNF.
Features based on ETSI NFV specifications, REST API and data models:
ETSI NFV-SOL003 v2.6.1: VNF Lifecycle Management(Scale VNF, Update VNF and Rollback VNF)
ETSI NFV-SOL005 v2.6.1: Fetch VNF Package Artifacts
Kubernetes VIM is extended to use ETSI NFV-SOL based operations. The major version of resources such as Deployment, DaemonSet, StatefulSet, and ReplicaSet can be deployed as VNF with Instantiate VNF operation.
The 5.0.0 release includes new features based on ETSI NFV-SOL Release2 specifications. The major changes are:
Day2 operations for Cloud-native Network Function (CNF). Scale operation for CNF and Heal operation for CNF with ETSI NFV-SOL003 v2.6.1 are supported.
New MgmtDriver as preamble and postamble of VNF Lifecycle Management.
<base_operation_name>_start
and<base_operation_name>_end
are executed before and after its operation according to the VNFD.Sample MgmtDriver for Kubernetes cluster VNF is provided to manage on-premise Kubernetes. HA Master nodes, Scaling Worker nodes, and Healing Master/Worker nodes are possible with Kube-adm.
Error handling of VNF instance is enhanced to support Retry, Rollback, and Fail operations.
New Features¶
This feature allows users to attach an already created or existing volume with VNF by providing volume_id in the TOSCA template. In this case, no new volume is created while vnf deployment.
Add placement constraints support so that the VNFM may interoperate with 3rd party NFVO, it enables to deploy each VM in the VNF after setting the zone information based on the grant response from NFVO.
Add new RESTful APIs for Scale VNF, Update VNF, and Rollback VNF operation based on ETSI NFV specifications.
Add new RESTful APIs for subscriptions and notifications based on ETSI NFV specifications. The client can use these resource to subscribe to notifications related to VNF lifecycle management, and to query its subscriptions.
Set vnfPkgId to related APIs in order to expand a wide range of NFV related equipments. See the spec for more details.
Add following ETSI NFV SOL003 specification compliant operations to cooperate with 3rd-Party NFVOs as VNFM.
VNF package management interface to obtain VNF package information
Granting interface to allow the VNFM to request a grant for authorization of a VNF lifecycle operation.
Add new RESTful APIs for Fail VNF, Retry VNF as part of error handling operation based on ETSI NFV specifications.
Adds Container based VNF support with ESTI NFV-SOL003 v2.6.1 VNF Lifecycle Management. Users can create, instantiate, terminate, and delete VNF on Kubernetes VIM. The Kubernetes resource files are available as VNFD and uploaded as a part of VNF Package.
MgmtDriver function configures applications provided by VNF vendors. VNF vendors can customize configuration methods for applications via MgmtDriver. These customizations are specified by “interface” definition in ETSI NFV-SOL001 v2.6.1. We provide the sample of MgmtDriver and scripts which can be used to deploy a Kubernetes cluster. The sample script for deploying Kubernetes cluster can be used in two cases. One is to deploy one master node with worker nodes. Under this case, it supports to scale worker node and heal worker node. The other is to deploy a high availability cluster, there are three(or more) master nodes with worker nodes. Under this case, it supports to scale worker node and to heal worker node and master node. In all the above cases, kubeadm is used for deploying Kubernetes in the sample script. We also provide a user guide to help users understand how to use this feature.
Instantiate single master node kubernetes cluster: The Kubernetes cluster can be instantiated with VNF Lifecycle Management Interface in ETSI NFV-SOL 003 v2.6.1.
Instantiate multi-master nodes kubernetes cluster: A Kubenrnetes cluster with a high availability (HA) configuration can be deployed.
Scale kubernetes worker node: Scaling operations on the Worker-nodes for the VNF including Kubernetes cluster is supported with MgmtDriver.
Heal kubernetes master and worker nodes: Healing operations on the Master-nodes and Worker-nodes for the VNF including Kubernetes cluster is supported with MgmtDriver.
Enable VNF vendors to customize configuration methods for applications via MgmtDriver. These customizations are specified by “interface” definition in ETSI NFV-SOL001 v2.6.1. With MgmtDriver, users can execute preamble and postamble of the base LCM operation. Customization of LCM itself is not supported by MgmtDriver.
Add Container based VNF heal operation support with ETSI NFV-SOL002 and SOL003 v2.6.1 VNF Lifecycle Management. For “Heal VNFC with SOL002”, users can heal Pod (mapped as VNFC) that is singleton or created using controller resources such as Kubernetes Deployment, DaemonSet, StatefulSet, and ReplicaSet. For “Heal VNF instance with SOL003”, users can heal entire VNF instance by termination and instantiation of the VNF. And the VNFC resource information are stored and updated for the heal operation of the Pod.
Add Container based VNF scale operation support with ETSI NFV-SOL003 v2.6.1 VNF Lifecycle Management. Users can scale the number of pod replicas managed by controller resources such as Kubernetes Deployment, StatefulSet, and ReplicaSet.
Upgrade Notes¶
The default value of
[oslo_policy] policy_file
config option has been changed frompolicy.json
topolicy.yaml
. Operators who are utilizing customized or previously generated static policy JSON files (which are not needed by default), should generate new policy files or convert them in YAML format. Use the oslopolicy-convert-json-to-yaml tool to convert a JSON to YAML formatted policy file in backward compatible way.
Deprecation Notes¶
Use of JSON policy files was deprecated by the
oslo.policy
library during the Victoria development cycle. As a result, this deprecation is being noted in the Wallaby cycle with an anticipated future removal of support byoslo.policy
. As such operators will need to convert to YAML policy files. Please see the upgrade notes for details on migration of any custom policy files.
Bug Fixes¶
Fixes bug 1879436. Users who build VNF packages can specify software image properties like min_disk, min_ram and size in different units as mentioned in section 3.2.6.4 of TOSCA Simple Profile in YAML Version 1.2 template. These property values are converted from various units to
byte
unit and returned in GET /vnfpkgm/v1/vnf_packages/{vnf_package_id} API response.Note
For old vnf packages, the software image properties are not converted into
byte
unit.