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
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. Copyright 2017 Huawei Technologies Co., Ltd.
VNF Package Tools User Guide
============================
VNF Package Designer, provides VNF product DevOps engineers with a graphical
tool to define the VNF product model and package content. It is made available
as part of the VNF Supplier SDK tools.The package designer makes use of the VNF
SDK command line interfaces (CLIs) and client-side API language bindings in
order to define the model and the package content. As such, it is functionally
equivalent to the VNF SDK tools.
VNF SDK - Guide for Bundling VNFs
---------------------------------
Step 1: Requirements
~~~~~~~~~~~~~~~~~~~~
1. Virtual machine images for each of your VDUs (likely in qcow2 format).
2. Scripts for installing and configuring each VDU per the standard TOSCA
lifecycle workflows.
3. Optional: scripts for retrieving indicators from each VDU.
4. VNF SDK pkgtools
Step 2: Start with the provided VNF blueprint as a template
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The VNF SDK comes with a "pingpong.yaml" template.
Copy the file and rename it as is appropriate for your VNF.
Step 3: Edit the VNF blueprint
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You will need a node template for each VDU, which in turn has a "dependency"
requirement on a host (a Compute node template).
The "dependency" requirement should have a relationship of type
"vnfsdk.DependsOn".
There are two optional properties you can assign to this relationship:
1. "indicators" is a map of indicators. The keys are arbitrary, for you to
name, and depend on the specific capabilities of your VNF. These provide
the link between TOSCA and your indicator retrieval scripts.
2. "compute_dependencies" is a map of features you require the infrastructure
to provide for the compute node hosting your VDU. The keys are arbitrary,
however we will maintain a master list of names supported by various
orchestrators (TBD). Note that new names will likely be supported in the
future as technological innovation progresses, while deprecated ones will be
ignored by orchestrators. Likewise, names unsupported by a particular
orchestrator will be ignored.
Notes:
1. For "compute_dependencies", you have the option of specifying a single
special key, "profile", that refers to a bundle of compute dependencies
specified in "compute-profiles.yaml". Optionally, you can override any of
the dependencies in the bundle by specifying them explicitly under
"compute_dependencies".
2. By default, compute dependencies are considered to be absolute requirements
for your VNF to function. However, if your VNF can also function without
them, you can set "optional: true". This way the orchestrator will try to
satisfy the optional requirements, but will not report an error if it
cannot.
3. You may optionally consider allowing operators to override your
dependencies. This is useful for allowing the VNF to run on various compute
infrastructures other than the defaults you specify, as long as they are
indeed supported by your VNF. In TOSCA, this is easily handled by declaring
"inputs" for your blueprint, with "default" values, and then using the
"get_input" intrinsic function to apply the provided value to any specific
"compute_dependencies". The "pingpong.yaml" has an example of such usage.
The same technique can be used to allow the operator to override your
indicator scripts, and there is an example of that as well.
Otherwise, this is a standard TOSCA blueprint using the Simple Profile for NFV,
and you may extend the blueprint as is required.
Step 4: Bundle the VNF
~~~~~~~~~~~~~~~~~~~~~~
Arrange all your files (the TOSCA template, your scripts, and your virtual
machine images) in the correct directory structure. File references provided in
the blueprint must match the directory structure. If a script is referenced
using a path with sub-directory "example" the initial directory must contain a
directory called "example" with that script file inside. The directory
structure will be kept inside the CSAR archive.
Run the bundling tool that is included in the VNF SDK.
The result will be a ".csar" file that can now be deployed by operators.
|
