the resource OS::Nova::Server. See `Resource:  OS::Nova::Server - Parameters`_.
 
    -  R-97199 The VNF Heat **MUST** use the metadata property for OS::Nova::Server resource type.
-                
+
 -  depends\_on
 
    -  Dependencies of the resource on one or more resources of the
 -  An ONAP Volume Module Output Parameter is available as an input
    parameter (i.e., declared in the parameters: section) only for the
    module (base or incremental) that the Cinder volume module is
-   associated with. 
+   associated with.
 
 -  R-07443 The VNF Heat **MUST** match the Output parameter name and type with the
    input parameter name and type unless the Output parameter is of the
 2. R-15422 The VNF Heat **MUST NOT** be prefixed with a common {vm-type}
    identifier the parameter referring to the OS::Nova::Server property
    availability\_zone . availability\_zone is described in `Property: availability_zone`_.
-   
+
 {network-role}
 ^^^^^^^^^^^^^^^
 
 R-84322 The VNF Heat **MUST** include
 int\_{network-role} as part of the parameter name for any parameter that is associated with an internal network.
 
-R-96983 The VNF Heat **MUST** include 
+R-96983 The VNF Heat **MUST** include
 int\_{network-role} as part of the resource ID for any resource ID that is associated with an internal network.
 
 Note that {network-role} must not be a substring of {vm-type}. A
    nested heat template.
 
 -  R-11041 The VNF Heat **MUST** have the resource calling the nested yaml file pass
-   in as properties all parameters defined in nested yaml file. 
-   
+   in as properties all parameters defined in nested yaml file.
+
 -  R-61183 The VNF Heat **MUST NOT** change the parameter names, when OS::Nova::Server metadata parameters are past into a nested heat
    template.
 
 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
 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