summaryrefslogtreecommitdiffstats
path: root/docs/files/VNF SDK - Guide for Bundling VNFs.rst
diff options
context:
space:
mode:
Diffstat (limited to 'docs/files/VNF SDK - Guide for Bundling VNFs.rst')
-rw-r--r--docs/files/VNF SDK - Guide for Bundling VNFs.rst43
1 files changed, 21 insertions, 22 deletions
diff --git a/docs/files/VNF SDK - Guide for Bundling VNFs.rst b/docs/files/VNF SDK - Guide for Bundling VNFs.rst
index 5a4dc81..2cb1556 100644
--- a/docs/files/VNF SDK - Guide for Bundling VNFs.rst
+++ b/docs/files/VNF SDK - Guide for Bundling VNFs.rst
@@ -29,34 +29,34 @@ The "dependency" requirement should have a relationship of type
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.
+ 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.
+ 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".
+ "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.
+ 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.
+ 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.
@@ -74,4 +74,3 @@ 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.
-