diff options
| -rw-r--r-- | docs/Chapter5.rst | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/docs/Chapter5.rst b/docs/Chapter5.rst index dc73969..eff10e0 100644 --- a/docs/Chapter5.rst +++ b/docs/Chapter5.rst @@ -5099,12 +5099,12 @@ even in the short-term as of the long-term direction. c. VNFM Driver Development Steps ================================ -Refer to the ONAP documentation for VNF Provider instructions on integrating +Refer to the ONAP documentation for VNF Provider instructions on integrating vendor-specific VNFM adaptors with VF-C. The VNF driver development steps are -highlighted below. +highlighted below. 1. Use the VNF SDK tools to design the VNF with TOSCA models to output -the VNF TOSCA package. Using the VNF SDK tools, the VNF package can be +the VNF TOSCA package. Using the VNF SDK tools, the VNF package can be validated and tested. 2. The VNF Provider supplies a vendor-specific VNFM driver in ONAP, which @@ -5119,8 +5119,8 @@ VNFs can be managed by vendor-specific VNFMs. To add a vendor-specific VNFM to O vendor-specific VNFM adaptor is added to ONAP implementing the interface of the vendor-specific VNFM. A vendor-specific VNFM adaptor is a microservice with a unique name and an appointed -port. When started up, the vendor-specific VNFM adaptor microservice is automatically registered to the -Microservices Bus (MSB). The following RESTful example describes the scenario of +port. When started up, the vendor-specific VNFM adaptor microservice is automatically registered to the +Microservices Bus (MSB). The following RESTful example describes the scenario of registering a vendor-specific VNFM adaptor to MSB: .. code-block:: java |