Get V271 Vnfpkgm V2 Onboarded Vnf Packages Vnfd Id Vnfd
Query VNF Package Info 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 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 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. EXAMPLE 1: Assuming a request is sent for the following VNF package (as described in clause A.1 in ETSI GS NFV-SOL 004): !------TOSCA-Metadata !----- TOSCA.meta (metadata for navigating the ZIP file) !------Definitions !----- MRF.yaml (main VNFD file) !----- OtherTemplates (e.g. type definitions, referenced by the main VNFD file) !------Files !----- ChangeLog.txt !----- image(s) !----- other artifacts !------Tests !----- file(s) !------Licenses !----- file(s) !------Scripts !----- install.sh !----- MRF.mf
The NFVO will return a ZIP file of the following format:
!------TOSCA-Metadata
!----- TOSCA.meta
!------Definitions
!----- MRF.yaml
!----- OtherTemplates
EXAMPLE 2: Assuming a request is sent for the following VNF package (a VNF package without a TOSCA-Metadata directory, as described in clause A.2 in ETSI GS NFV-SOL 004): !------MRF.yaml (main VNFD file) !------MRF.mf !------ChangeLog.txt !------Tests !----- file(s) !------Licenses !----- file(s) !------Artifacts !----- install.sh !----- start.yang
The NFVO will return a ZIP file of the following format:
!------MRF.yaml
EXAMPLE 3: Assuming a request is sent for the following VNF package (a VNF package with the YANG VNFD without a TOSCA-Metadata directory, as described in clause A.3 in ETSI GS NFV SOL 004): !----CompanyVNFD.yaml !----CompanyVNFD.xml !----CompanyVNFD.mf !----ChangeLog.txt !-----Files !-----Instance Data Files !---- start.xml !-----Licenses !-----Scripts !----- install.sh
The NFVO will return a ZIP file of the following format:
!----CompanyVNFD.yaml
!----CompanyVNFD.xml (indicated in the yang_definitions metadata
in CompanyVNFD.yaml) This method shall follow the provisions specified in the tables 10.4.4.3.2-1 and 10.4.4.3.2-2 for URI query parameters, request and response data structures, nd response codes.
Identifier of the VNFD and the VNF package. The identifier is allocated by the VNF provider. This identifier can be retrieved from the "vnfdId" attribute in the VnfPackageOnboardingNotification or VnfPackageChangeNotification.
The tenant identifier
If this parameter is provided, the NFVO shall include in the ZIP archive the security information as specified above. This URI query parameter is a flag, i.e. it shall have no value. The NFVO shall support this parameter.
Content-Types that are acceptable for the response. Permitted values: "text/plain" and/or "application/zip" Reference: IETF RFC 7231
The authorization token for the request. Reference: IETF RFC 7235
Version of the API requested to use when responding to this request.
200 OK Shall be returned when the content of the VNFD has been read successfully. The payload body shall contain a copy of the file representing the VNFD or a ZIP file that contains the file or multiple files representing the VNFD, as specified above. The "Content-Type" HTTP header shall be set according to the format of the returned file, i.e. to "text/plain" for a YAML file or to "application/zip" for a ZIP file.
Response Headers
The MIME type of the body of the response.
Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
Version of the API used in the response.
{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string"
}A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
A human-readable explanation specific to this occurrence of the problem.
A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string"
}A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
A human-readable explanation specific to this occurrence of the problem.
A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string"
}A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
A human-readable explanation specific to this occurrence of the problem.
A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string"
}A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
A human-readable explanation specific to this occurrence of the problem.
A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string"
}A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
A human-readable explanation specific to this occurrence of the problem.
A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string"
}A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
A human-readable explanation specific to this occurrence of the problem.
A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string"
}A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
A human-readable explanation specific to this occurrence of the problem.
A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string"
}A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
A human-readable explanation specific to this occurrence of the problem.
A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string"
}A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
A human-readable explanation specific to this occurrence of the problem.
A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string"
}A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
A human-readable explanation specific to this occurrence of the problem.
A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.