Commit 4e8e17f2 authored by Francesca Moscatelli's avatar Francesca Moscatelli
Browse files

SOL003: v2.8.1 review fixes

parent dfc267e6
Pipeline #6774 passed with stage
in 0 seconds
......@@ -2096,7 +2096,7 @@ paths:
Shall be returned when the state of the VNF lifecycle management operation occurrence
has been changed successfully.
The response shall include a representation of the "Individual VNF lifecycle operation occurrence" resource.
The response body shall include a representation of the "Individual VNF lifecycle operation occurrence" resource.
headers:
Content-Type:
description: The MIME type of the body of the response.
......
......@@ -216,7 +216,7 @@ definitions:
The VNFM shall accept requests to write metadata that are not declared in the VNFD.
These attributes can be initialized with default values from the VNFD or with values
passed in the CreateVnfRequest structure (see clause 5.4.2.3.1).
This attributeThese attributes can be created, modified or removed with the PATCH method.
These attributes can be created, modified or removed with the PATCH method.
ETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.
Upon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes
......@@ -832,7 +832,7 @@ definitions:
$ref: "../../../definitions/SOL002SOL003VNFLifecycleManagement_def.yaml#/definitions/CpProtocolInfo"
vnfLinkPortId:
description: >
Identifier of the "VnfLinkPorts" structure in the
Identifier of the "VnfLinkPortInfo" structure in the
"VnfVirtualLinkResourceInfo" structure. Shall be present if the CP is associated to a link port
on an internal VL of the VNF instance and shall be absent otherwise.
$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVnf"
......@@ -1109,7 +1109,7 @@ definitions:
link instance, not the link port instance. The resource handles of the affected VNF link ports can
be found by dereferencing the identifiers in the "vnfLinkPortIds" attribute.
$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/ResourceHandle"
virtualLinkPortIds:
vnfLinkPortIds:
description: >
Identifiers of the link ports of the affected VL related to the change.
Each identifier references a "VnfLinkPortInfo" structure.
......@@ -1142,6 +1142,10 @@ definitions:
ports, the "networkResource" and "resourceDefinitionId" attributes refer to the affected virtual
link instance, not the link port instance. The resource handles of the affected VNF link ports can
be found by dereferencing the identifiers in the "vnfLinkPortIds" attribute.
NOTE 2: The "resourceDefinitionId" attribute provides information to the API consumer (i.e. the NFVO)
to assist in correlating the resource changes performed during the LCM operation with the granted
resources in a specific Grant exchange, which is identified by the "grantId" available in the "Individual
VNF lifecycle management operation occurrence" and the "id" in the "Individual Grant".
$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierLocal"
zoneId:
description: >
......
......@@ -238,7 +238,7 @@ paths:
get:
description: >
The GET method allows the server to test the notification endpoint that is provided by the API consumer,
The GET method allows the API producer to test the notification endpoint that is provided by the API consumer,
e.g. during subscription.
This method shall follow the provisions specified in the tables 5.4.20.3.2-1 and 5.4.20.3.2-2
for URI query parameters, request and response data structures, and response codes.
......@@ -370,7 +370,7 @@ paths:
get:
description: >
The GET method allows the server to test the notification endpoint that is provided by the API consumer,
The GET method allows the API producer to test the notification endpoint that is provided by the API consumer,
e.g. during subscription.
This method shall follow the provisions specified in the tables 5.4.20.3.2-1 and 5.4.20.3.2-2
for URI query parameters, request and response data structures, and response codes.
......
......@@ -445,7 +445,7 @@ definitions:
$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVnfd"
resourceTemplateId:
description: >
Reference to athe applicable resource template in the VNFD as follows:
Reference to the applicable resource template in the VNFD as follows:
- If type="VL": VnfVirtualLinkDesc,
- If type="COMPUTE": VirtualComputeDesc,
- If type="LINKPORT": VnfExtCpd,
......
......@@ -622,24 +622,41 @@ paths:
The GET method reads the content of the VNFD within a VNF package.
The VNFD is implemented as a collection of one or more files.
A ZIP archive embedding these files shall be returned when reading this resource.
The default format of the ZIP archive shall be the one specified in ETSI GS NFV-SOL 004
where only the files representing the VNFD and information needed to navigate the ZIP
archive and to identify the file that is the entry point for parsing the VNFD, and,
if requested, further security information are included. This means that the structure
of the ZIP archive shall correspond to the directory structure used in the VNF package
and that the archive shall contain the following files from the package:
• TOSCA.meta (if available in the package)
• The main TOSCA definitions YAML file (either as referenced from TOSCA.meta
or available as a file with the extension ".yml" or ".yaml" from the root of the archive)
• Every component of the VNFD referenced (recursively) from the main TOSCA definitions YAML file
• The related security information, if the "include_signatures" URI parameter is provided, as follows:
The default format of the ZIP archive shall comply with CSAR format as specified
in ETSI GS NFV-SOL 004 where only the files representing the VNFD and information
needed to navigate the ZIP archive and to identify the file that is the entry point
for parsing the VNFD, and, if requested, further security information are included,
and software images as well as other artifacts referenced from the YAML files are
excluded. This means that the structure of the ZIP archive shall correspond to the
directory structure used in the VNF package and that the archive shall contain the
following files from the package:
• TOSCA.meta (if available in the package).
• The main TOSCA definitions YAML file (either as referenced from TOSCA.meta or
available as a file with the extension ".yml" or ".yaml" from the root of the
archive).
• Every component of the VNFD referenced (recursively) from the main TOSCA definitions
YAML file.
NOTE 1: For a VNFD based on TOSCA, it includes all the imported type definition files
as indicated in the top level service template and in any of the lower level service
template if it has any as described in ETSI GS NFV-SOL 001.
NOTE 2: For a VNFD based on YANG, it includes the file as indicated by the
"yang_definitions" keyname in the metadata section of the main yaml file as described
in ETSI GS NFV-SOL 004.
• The related security information, if the "include_signatures" URI parameter is provided,
as follows:
- the manifest file
- the singleton certificate file in the root of the VNF package (if available in the package)
- the signing certificates of the individual files included in the ZIP archive (if available in the package)
- the singleton certificate file in the root of the VNF package (if available in the
package)
- the signing certificates of the individual files included in the ZIP archive
(if available in the package)
- the signatures of the individual files (if available in the package)
Three examples are provided below.
NOTE: These examples do not show the security related files.
NOTE 3: These examples do not show the security related files.
EXAMPLE 1: Assuming a request is sent for the following VNF package
(as described in clause A.1 in ETSI GS NFV-SOL 004):
......
......@@ -227,8 +227,9 @@ definitions:
VnfPackageSoftwareImageInfo:
description: >
This type represents an artifact contained in a VNF package which
represents a software image.
This type represents an artifact contained in or external to a VNF package
which represents a software image. It shall comply with provisions defined
in table 10.5.3.2-1
type: object
required:
- id
......
......@@ -156,7 +156,7 @@ definitions:
description: >
Attribute indicating if this fault is the root for other correlated
alarms. If true, then the alarms listed in the attribute
"correlatedAlarmId" are caused by this fault.
"correlatedAlarmIds" are caused by this fault.
type: boolean
correlatedAlarmIds:
description: >
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment