diff options
| -rw-r--r-- | docs/files/VNF SDK - Guide for Bundling VNFs.rst | 43 | ||||
| -rw-r--r-- | docs/files/marketplace-overview.rst | 5 | ||||
| -rw-r--r-- | docs/files/vnfsdk-apis.rst | 2 |
3 files changed, 24 insertions, 26 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. - diff --git a/docs/files/marketplace-overview.rst b/docs/files/marketplace-overview.rst index 14e0b91..18a5da9 100644 --- a/docs/files/marketplace-overview.rst +++ b/docs/files/marketplace-overview.rst @@ -1,11 +1,11 @@ VNF SDK Marketplace -================== +=================== VNF SDK provides a reference implementation "marketplace" to help vendors validate and manage VNF packages. It also supports the operator to onboard VNF into ONAP. |image0| -.. |image0| image:: files/vnfsdk-marketplace.png +.. |image0| image:: vnfsdk-marketplace.png :height: 600px :width: 800px @@ -27,4 +27,3 @@ VNF SDK provides a reference implementation "marketplace" to help vendors valida 3. **VNF SDK Integration with SDC** a. In Amsterdam release, the SDC-UI is being integrated with the VNF Repository backend. It provides seamless download, search, view of the VNF present in VNF repository. The user can onboard these validated VNF into the SDC catalogue. - diff --git a/docs/files/vnfsdk-apis.rst b/docs/files/vnfsdk-apis.rst index 3dec23b..b6819f9 100644 --- a/docs/files/vnfsdk-apis.rst +++ b/docs/files/vnfsdk-apis.rst @@ -83,7 +83,7 @@ Response: HTTP Success or Error Code -Download VNF package files� +Download VNF package files ++++++++++++++++++++++++++ +--------------------+--------------------------------------------+ |