1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
|
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. Copyright 2017 AT&T Intellectual Property. All rights reserved.
VNF Devops
---------------------
This section includes guidelines for VNF providers to ensure that a Network
Cloud Service Provider’s operations personnel have a common and
consistent way to support VNFs and VNFCs.
NCSPs may elect to support standard images to enable compliance with
security, audit, regulatory and other needs. As part of the overall VNF
software bundle, VNF suppliers using standard images would typically
provide the NCSP with an install package consistent with the default OS
package manager (e.g. aptitude for Ubuntu, yum for Redhat/CentOS).
Section 5.a DevOps in *VNF Guidelines* describes
the DevOps guidelines for VNFs.
DevOps Requirements
* R-46960 NCSPs **MAY** operate a limited set of Guest OS and CPU
architectures and families, virtual machines, etc.
* R-23475 VNFCs **SHOULD** be agnostic to the details of the Network Cloud
(such as hardware, host OS, Hypervisor or container technology) and must run
on the Network Cloud with acknowledgement to the paradigm that the Network
Cloud will continue to rapidly evolve and the underlying components of
the platform will change regularly.
* R-33846 The VNF **MUST** install the NCSP required software on Guest OS
images when not using the NCSP provided Guest OS images. [1]_
* R-09467 The VNF **MUST** utilize only NCSP standard compute flavors. [1]_
* R-02997 The VNF **MUST** preserve their persistent data. Running VMs
will not be backed up in the Network Cloud infrastructure.
* R-29760 The VNFC **MUST** be installed on non-root file systems,
unless software is specifically included with the operating system
distribution of the guest image.
* R-20860 The VNF **MUST** be agnostic to the underlying infrastructure
(such as hardware, host OS, Hypervisor), any requirements should be
provided as specification to be fulfilled by any hardware.
* R-89800 The VNF **MUST NOT** require Hypervisor-level customization
from the cloud provider.
* R-86758 The VNF **SHOULD** provide an automated test suite to validate
every new version of the software on the target environment(s). The tests
should be of sufficient granularity to independently test various
representative VNF use cases throughout its lifecycle. Operations might
choose to invoke these tests either on a scheduled basis or on demand to
support various operations functions including test, turn-up and
troubleshooting.
* R-39650 The VNF **SHOULD** provide the ability to test incremental
growth of the VNF.
* R-14853 The VNF **MUST** respond to a "move traffic" [2]_ command
against a specific VNFC, moving all existing session elsewhere with
minimal disruption if a VNF provides a load balancing function across
multiple instances of its VNFCs. Note: Individual VNF performance
aspects (e.g., move duration or disruption scope) may require further
constraints.
* R-06327 The VNF **MUST** respond to a "drain VNFC" [2]_ command against
a specific VNFC, preventing new session from reaching the targeted VNFC,
with no disruption to active sessions on the impacted VNFC, if a VNF
provides a load balancing function across multiple instances of its VNFCs.
This is used to support scenarios such as proactive maintenance with no
user impact.
* R-64713 The VNF **SHOULD** support a software promotion methodology
from dev/test -> pre-prod -> production in software, development &
testing and operations.
.. [1]
Refer to NCSP’s Network Cloud specification
.. [2]
Not currently supported in ONAP release 1
|
