diff options
Diffstat (limited to 'docs/files/VNF SDK - Guide for Bundling VNFs.rst')
| -rw-r--r-- | docs/files/VNF SDK - Guide for Bundling VNFs.rst | 43 |
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. - |