Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • nfv/api-tests
  • reinaortega/api-tests
2 results
Show changes
Commits on Source (929)
829 additional commits have been omitted to prevent performance issues.
Hide whitespace changes
Inline Side-by-side
Showing
with 1703 additions and 4102 deletions
.gitignore 0 → 100644
View file @ 132ae1a2
/.project
/.pydevproject
/red.xml
build/
dist/
/libspecs/
.jenkins.sh 0 → 100644
View file @ 132ae1a2
#!/bin/bash
# Copyright ETSI 2018
# See: https://forge.etsi.org/etsi-forge-copyright-statement.txt
#set -vx
#set -e
cd "$(dirname "$0")"
run_dir="$(pwd)"
echo "Using git branch $GIT_BRANCH"
bash ./scripts/build-container.sh
ret=$?
if [ "$ret" != "0" ]; then
echo "build-container.sh failed"
exit -1
fi
bash ./scripts/run-container.sh "${run_dir}" "$GIT_BRANCH"
ret=$?
if [ "$ret" != "0" ]; then
echo "run-container.sh failed"
exit -1
fi
if [[ "$GIT_BRANCH" =~ .*fix-plu$ ]]; then
apiTestsVersion=$(echo $GIT_BRANCH | cut -d'/' -f 2)
apiTestsVersion=$(echo $apiTestsVersion | cut -d'-' -f 1)
echo apiTestsVersion
curl -X POST \
-F token=${ROBOT_HIVE_TAP_TT_TOKEN} \
-F ref=master \
-F "variables[API_TESTS_VERSION]=$apiTestsVersion" \
-F "variables[TEST_SUITE]=NFV" \
https://forge.etsi.org/rep/api/v4/projects/484/trigger/pipeline
fi
ret=$?
echo "Final validation result: $ret"
exit $ret
.settings/org.eclipse.core.resources.prefs 0 → 100644
View file @ 132ae1a2
eclipse.preferences.version=1
encoding//libspecs/REST.py=utf-8
LICENSE
View file @ 132ae1a2
ETSI Software License
Copyright 2019-2020 ETSI
As long as the hereunder conditions are respected, non-exclusive permission is
hereby granted, free of charge, to use, reproduce and modify this software
source code, under the following conditions:
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
3. Neither the name of the copyright holder nor the names of its contributors
may be used to endorse or promote products derived from this software without
specific prior written permission.
- This source code is provided “AS IS” with no warranties, express or implied,
including but not limited to, the warranties of merchantability, fitness for
a particular purpose and warranties for non-infringement of intellectual
property rights. ETSI shall not be held liable in any event for any direct or
indirect damages whatsoever (including, without limitation, damages for loss
of profits, business interruption, loss of information, or any other pecuniary
loss) arising out of or related to the use of or inability to use the
source code.
- This permission is granted to facilitate the implementation of the related
ETSI standard, provided that ETSI is given the right to use, reproduce and
amend the modified source code under the same conditions as the
present permission.
- This permission does not apply to any documentation associated with this
source code for which ETSI keeps all rights reserved.
The present ETSI Source Code license shall be included in all copies of whole
or part of this source code and shall not imply any sub-license right.
\ No newline at end of file
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
OF THE POSSIBILITY OF SUCH DAMAGE.
README.md
View file @ 132ae1a2
# NFV API Conformance Test Specification
This repository hosts the NFV API Conformance test specification for
the APIs defined in ETSI NFV GS [SOL002](https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.04.01_60/gs_NFV-SOL002v020401p.pdf), [SOL003](https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.04.01_60/gs_NFV-SOL003v020401p.pdf), [SOL005](http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/005/02.04.01_60/gs_NFV-SOL005v020401p.pdf), in their versions v2.4.1.
## Disclaimer
This repository contains working test cases implemented using the Robot
framework. It is provided for information only and is still under development.
The test cases may be updated, deleted, replaced, or obsoleted by other
contents at any time. As test cases are approved, they will be reflected
in the normative provisions of
[GS NFV-TST010](https://docbox.etsi.org/isg/nfv/open/Drafts/TST010_API_Conformance_Testing).
The material in this repository does not guarantee the full compliance
to the SOL specifications. The normative provisions of the test suite,
including the scope of the test cases, are still under development.
## Overview
The Test Specification is built as a collection of [Robot Framework](robotframework.org/) Test Description. [Robot Framework](robotframework.org/) is a generic test automation framework for acceptance testing and acceptance test-driven development.
**IMPORTANT: This repository and the NFV API Conformance Test Specification is Work in Progress. The current version focuses on conformance tests of individual SOL002 and SOL003 resource endpoints. The [Robot Framework](robotframework.org/) Test Descriptions are expected to be consolidated and reviewed in the short term, and possibly re-organized to ease automation of NFV workflows testing. SOL005 Test Descriptions are under development and will be contributed during Q1-2019.**
More information at [NFV API Conformance Test Specification wiki](https://forge.etsi.org/gitlab/nfv/api-tests/wikis/NFV-API-Conformance-Test-Specification).
# NFV API Conformance Test Specification (NFV-TST 010)
This repository hosts the NFV API Conformance test specification for
the APIs defined in ETSI NFV GS [SOL002](https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.08.01_60/gs_NFV-SOL002v020801p.pdf),
[SOL003](https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.08.01_60/gs_NFV-SOL003v020801p.pdf),
[SOL005](https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/005/02.08.01_60/gs_NFV-SOL005v020801p.pdf), in their versions
v2.8.1.
More information and download is available at [DGS/NFV-TST010ed281](https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=63121).
## Available versions
The NFV API Conformance test specification is available in the following versions:
| TST010 Version | SOL Specifications | API Conformance Tests |
|----------------------|-----------------------------------------------------------------------------------------|-----------------------------------------------------------|
| v2.4.1 | SOL002 SOL003 SOL005 v2.4.1 | [v2.4.1](https://forge.etsi.org/rep/nfv/api-tests/tree/2.4.1/) |
| v2.4.1-maintenance | SOL002 SOL003 SOL005 v2.4.1 | [v2.4.1-fix-plu](https://forge.etsi.org/rep/nfv/api-tests/tree/2.4.1-fix-plu/) |
| v2.6.1 | SOL002 SOL003 SOL005 v2.6.1 | [v2.6.1](https://forge.etsi.org/rep/nfv/api-tests/tree/2.6.1/) |
| v2.6.1-maintenance | SOL002 SOL003 SOL005 v2.6.1 | [v2.6.1-fix-plu](https://forge.etsi.org/rep/nfv/api-tests/tree/2.6.1-fix-plu/) |
| v2.7.1 | SOL002 SOL003 SOL005 v2.7.1 | [v2.7.1](https://forge.etsi.org/rep/nfv/api-tests/tree/2.7.1/) |
| v2.7.1-maintenance | SOL002 SOL003 SOL005 v2.7.1 | [v2.7.1-fix-plu](https://forge.etsi.org/rep/nfv/api-tests/tree/2.7.1-fix-plu/)
| v2.8.1 | SOL002 SOL003 SOL005 v2.8.1 | [v2.8.1](https://forge.etsi.org/rep/nfv/api-tests/tree/2.8.1/) |
| v2.8.1-maintenance | SOL002 SOL003 SOL005 v2.8.1 | [v2.8.1-fix-plu](https://forge.etsi.org/rep/nfv/api-tests/tree/2.8.1-fix-plu/)|
| v3.3.1 | SOL002 SOL003 SOL005 v3.3.1<br>SOL009 SOL011 v3.3.1<br>SOL012 v3.4.1 | [v3.3.1](https://forge.etsi.org/rep/nfv/api-tests/tree/3.3.1/) |
| v3.3.1-maintenance | SOL002 SOL003 SOL005 v3.3.1<br>SOL009 SOL011 v3.3.1<br>SOL012 v3.4.1 | [v3.3.1-fix-plu](https://forge.etsi.org/rep/nfv/api-tests/tree/3.3.1-fix-plu/) |
| v3.5.1 | SOL002 SOL003 SOL005 v3.5.1<br>SOL009 v3.5.1<br>SOL011 v3.3.1<br>SOL012 v3.4.1 | [v3.5.1](https://forge.etsi.org/rep/nfv/api-tests/tree/3.5.1/) |
| v3.5.1-maintenance | SOL002 SOL003 SOL005 v3.5.1<br>SOL009 v3.5.1<br>SOL011 v3.3.1<br>SOL012 v3.4.1 | [v3.5.1-fix-plu](https://forge.etsi.org/rep/nfv/api-tests/tree/3.5.1-fix-plu/) |
| v3.6.1 | SOL002 SOL003 SOL005 v3.6.1<br>SOL009 v3.6.1<br>SOL011 v3.3.1<br>SOL012 v3.4.1 | [v3.6.1](https://forge.etsi.org/rep/nfv/api-tests/tree/3.6.1/) |
| v3.6.1-maintenance | SOL002 SOL003 SOL005 v3.6.1<br>SOL009 v3.6.1<br>SOL011 v3.3.1<br>SOL012 v3.4.1 | [v3.6.1-fix-plu](https://forge.etsi.org/rep/nfv/api-tests/tree/3.6.1-fix-plu/) |
## Test Specification Overview
The Test Specification is built as a collection of [Robot Framework](robotframework.org/) Test Description. [Robot Framework](robotframework.org/) is a generic test automation framework for acceptance testing and acceptance
test-driven development.
More information at [NFV API Conformance Test Specification wiki](https://forge.etsi.org/rep/nfv/api-tests/wikis/NFV-API-Conformance-Test-Specification).
## How to raise issues
Change requests can be filed at [ETSI Forge Bugzilla](<LINK>). Please report errors, bugs or other issues [here](https://forge.etsi.org/bugzilla/enter_bug.cgi?product=NFV).
Please report errors, bugs or other issues [here](https://forge.etsi.org/rep/nfv/api-tests/issues).
## How to contribute
ETSI Forge uses Gitlab to manage submissions to the repository.
For more information on setting up your environment and contributing, you may refer to the [ETSI Forge wiki](https://forge.etsi.org/wiki/index.php/Main_Page).
## License
Copyright (c) ETSI 2018.
This software is subject to copyrights owned by ETSI. Non-exclusive permission
is hereby granted, free of charge, to copy, reproduce and amend this file
under the following conditions: It is provided "as is", without warranty of any
kind, expressed or implied.
ETSI shall never be liable for any claim, damages, or other liability arising
from its use or inability of use.This permission does not apply to any documentation
associated with this file for which ETSI keeps all rights reserved. The present
copyright notice shall be included in all copies of whole or part of this
file and shall not imply any sub-license right.
SOL002/README.md
View file @ 132ae1a2
......@@ -2,7 +2,7 @@
This folder includes the NFV API conformance test descriptions for NFV SOL002 APIs.
The reference spec version is v2.4.1: https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.04.01_60/gs_NFV-SOL002v020401p.pdf
The reference spec version is v2.7.1: https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.07.01_60/gs_NFV-SOL002v020701p.pdf
## License
......
SOL002/VNFConfiguration-API/ApiVersion.robot 0 → 100644
View file @ 132ae1a2
*** Settings ***
Resource environment/variables.txt
Library REST ${EM-VNF_SCHEMA}://${EM-VNF_HOST}:${EM-VNF_PORT} ssl_verify=false
Library DependencyLibrary
Library JSONLibrary
Library JSONSchemaLibrary schemas/
*** Test Cases ***
POST API Version - Method not implemented
[Documentation] Test ID: 6.3.1.2.1
... Test title: POST API version - Method not implemented
... Test objective: The objective is to test that POST method is not implemented
... Pre-conditions: none
... Reference: Clause 9.3.3.3.1 - ETSI GS NFV-SOL 013 v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
POST API Version
Check HTTP Response Status Code Is 405
GET API Version
[Documentation] Test ID: 6.3.1.2.2
... Test title: GET API Version
... Test objective: The objective is to test that GET method successfully return ApiVersionInformation
... Pre-conditions: none
... Reference: Clause 9.3.3.3.2 - ETSI GS NFV-SOL 013 v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
GET API Version
Check HTTP Response Status Code Is 200
Check HTTP Response Body Json Schema Is ApiVersionInformation
PUT API Version - Method not implemented
[Documentation] Test ID: 6.3.1.2.3
... Test title: PUT API Version - Method not implemented
... Test objective: The objective is to test that PUT method is not implemented
... Pre-conditions: none
... Reference: Clause 9.3.3.3.3 - ETSI GS NFV-SOL 013 v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
PUT API Version
Check HTTP Response Status Code Is 405
PATCH API Version - Method not implemented
[Documentation] Test ID: 6.3.1.2.4
... Test title: PATCH API Version - Method not implemented
... Test objective: The objective is to test that PATCH method is not implemented
... Pre-conditions: none
... Reference: Clause 9.3.3.3.4 - ETSI GS NFV-SOL 013 v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
PATCH API Version
Check HTTP Response Status Code Is 405
DELETE API Version - Method not implemented
[Documentation] Test ID: 6.3.1.2.5
... Test title: DELETE API Version - Method not implemented
... Test objective: The objective is to test that DELETE method is not implemented
... Pre-conditions: none
... Reference: Clause 9.3.3.3.5 - ETSI GS NFV-SOL 013 v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
DELETE API Version
Check HTTP Response Status Code Is 405
POST API Version with apiMajorVerion - Method not implemented
[Documentation] Test ID: 6.3.1.2.6
... Test title: POST API version with apiMajorVerion - Method not implemented
... Test objective: The objective is to test that POST method is not implemented
... Pre-conditions: none
... Reference: Clause 9.3.3.3.1 - ETSI GS NFV-SOL 013 v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
POST API Version
Check HTTP Response Status Code Is 405
GET API Version with apiMajorVerion
[Documentation] Test ID: 6.3.1.2.7
... Test title: GET API Version with apiMajorVerion
... Test objective: The objective is to test that GET method successfully return ApiVersionInformation
... Pre-conditions: none
... Reference: Clause 9.3.3.3.2 - ETSI GS NFV-SOL 013 v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
GET API Version
Check HTTP Response Status Code Is 200
Check HTTP Response Body Json Schema Is ApiVersionInformation
PUT API Version with apiMajorVerion - Method not implemented
[Documentation] Test ID: 6.3.1.2.8
... Test title: PUT API Version with apiMajorVerion - Method not implemented
... Test objective: The objective is to test that PUT method is not implemented
... Pre-conditions: none
... Reference: Clause 9.3.3.3.3 - ETSI GS NFV-SOL 013 v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
PUT API Version
Check HTTP Response Status Code Is 405
PATCH API Version with apiMajorVerion - Method not implemented
[Documentation] Test ID: 6.3.1.2.9
... Test title: PATCH API Version with apiMajorVerion - Method not implemented
... Test objective: The objective is to test that PATCH method is not implemented
... Pre-conditions: none
... Reference: Clause 9.3.3.3.4 - ETSI GS NFV-SOL 013 v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
PATCH API Version
Check HTTP Response Status Code Is 405
DELETE API Version with apiMajorVerion - Method not implemented
[Documentation] Test ID: 6.3.1.2.10
... Test title: DELETE API Version with apiMajorVerion - Method not implemented
... Test objective: The objective is to test that DELETE method is not implemented
... Pre-conditions: none
... Reference: Clause 9.3.3.3.5 - ETSI GS NFV-SOL 013 v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
DELETE API Version
Check HTTP Response Status Code Is 405
*** Keywords ***
POST API Version
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Post ${apiRoot}/${apiName}/api_versions
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
GET API Version
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Get ${apiRoot}/${apiName}/api_versions
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
PUT API Version
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Put ${apiRoot}/${apiName}/api_versions
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
PATCH API Version
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Patch ${apiRoot}/${apiName}/api_versions
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
DELETE API Version
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Delete ${apiRoot}/${apiName}/api_versions
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
POST API Version with apiMajorVersion
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Post ${apiRoot}/${apiName}/${apiMajorVersion}/api_versions
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
GET API Version with apiMajorVersion
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Get ${apiRoot}/${apiName}/${apiMajorVersion}/api_versions
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
PUT API Version with apiMajorVersion
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Put ${apiRoot}/${apiName}/${apiMajorVersion}/api_versions
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
PATCH API Version with apiMajorVersion
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Patch ${apiRoot}/${apiName}/${apiMajorVersion}/api_versions
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
DELETE API Version with apiMajorVersion
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Delete ${apiRoot}/${apiName}/${apiMajorVersion}/api_versions
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
Check HTTP Response Status Code Is
[Arguments] ${expected_status}
Should Be Equal As Strings ${response['status']} ${expected_status}
Log Status code validated
Check HTTP Response Body Json Schema Is
[Arguments] ${input}
${schema} = Catenate SEPARATOR= ${input} .schema.json
Validate Json ${schema} ${response['body']}
Log Json Schema Validation OK
\ No newline at end of file
SOL002/VNFConfiguration-API/Configuration.robot
View file @ 132ae1a2
*** Settings ***
Resource environment/variables.txt
Library REST ${VNF_SCHEMA}://${VNF_HOST}:${VNF_PORT}
... spec=SOL002-VNFConfiguration-API.yaml
Library REST ${EM-VNF_SCHEMA}://${EM-VNF_HOST}:${EM-VNF_PORT} ssl_verify=false
Library JSONLibrary
Library JSONSchemaLibrary schemas/
Library OperatingSystem
Library DependencyLibrary
*** Variables ***
${Etag}= an etag
${Etag_modified}= a modified etag
*** Test Cases ***
PATCH Set a new VNF Configuration
[Documentation] Test ID: 6.3.1.1.1
... Test title: PATCH Set a new VNF Configuration
... Test objective: The objective is to test the creation of a new VNF configuration and perform a JSON schema validation of the returned configuration data structure
... Pre-conditions: A VNF instance is instantiated
... Reference: Clause 9.4.2.3.4 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VE
... Applicability: The VNF supports the generation of HTTP Etag opaque identifiers
... Post-Conditions: The configuration is successfully set in the VNF and it matches the issued configuration
Send VNF configuration
Check HTTP Response Status Code Is 200
Check HTTP Response Header Contains ETag
Check HTTP Response Body Json Schema Is vnfConfigModifications
Check Postcondition VNF Is Configured
*** Test cases ***
POST Configuration - Method not implemented
log Trying to perform a POST. This method should not be implemented
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Post ${apiRoot}/${apiName}/${apiVersion}/configuration
Log Validate Status code
Integer response status 405
Get information about a VNF configuration
[Tags] no-etag
[Documentation] Test ID: 6.3.1.1.2
... Test title: Get information about a VNF configuration
... Test objective: The objective is to test the retrieval of an existing VNF instance configuration and perform a JSON schema validation of the collected configuration data structure
... Pre-conditions: A VNF instance is instantiated. The VNF instance is already configured.
... Reference: Clause 9.4.2.3.2 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VE
... Applicability: none
... Post-Conditions: none
Get VNF configuration
Check HTTP Response Status Code Is 200
Check HTTP Response Body Json Schema Is vnfConfiguration
Get information about a VNF configuration with HTTP Etag
[Tags] etag
[Documentation] Test ID: 6.3.1.1.3
... Test title: Get information about a VNF configuration with HTTP Etag
... Test objective: The objective is to test the retrieval of an existing VNF instance configuration, check the generation by the VNF of an HTTP Etag opaque identifier, and perform a JSON schema validation of the collected configuration data structure
... Pre-conditions: A VNF instance is instantiated. The VNF instance is already configured
... Reference: Clause 9.4.2.3.2 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VE
... Applicability: The VNF supports the generation of HTTP Etag opaque identifiers
... Post-Conditions: none
Get VNF configuration
Check HTTP Response Status Code Is 200
Check HTTP Response Header Contains ETag
Check HTTP Response Body Json Schema Is vnfConfiguration
PATCH VNF Configuration - HTTP Etag precondition unsuccessful
[Tags] etag
[Documentation] Test ID: 6.3.1.1.4
... Test title: PATCH VNF Configuration - HTTP Etag precondition unsuccessful
... Test objective: The objective is to test the unsuccess in setting a duplication of VNF configuration identified by an already used HTTP Etag identifier. The test also checks the JSON schema of the unsuccessful operation HTTP response.
... Pre-conditions: A VNF instance is instantiated. The VNF instance is already configured (Test ID 6.3.1.1.1) with a given HTTP Etag identifier.
... Reference: Clause 9.4.2.3.4 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VE
... Applicability: The VNF supports the generation of HTTP Etag opaque identifiers
... Post-Conditions: The VNF configuration is not modified by the unsuccessful operation and it matches the configuration issued in Test ID 6.3.1.1.1
Send Duplicated VNF configuration
Check HTTP Response Status Code Is 412
Check HTTP Response Body Json Schema Is ProblemDetails
Check Postcondition VNF Configuration Unmodified (Implicit)
POST VNF Configuration - Method not implemented
[Documentation] Test ID: 6.3.1.1.5
... Test title: POST VNF Configuration - Method not implemented
... Test objective: The objective is to test that POST method is not allowed to create a new VNF configuration
... Pre-conditions: none
... Reference: Clause 9.4.2.3.1 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VE
... Applicability: none
... Post-Conditions: none
Send POST Request for VNF Configuration
Check HTTP Response Status Code Is 405
Get information about a configuration
PUT VNF Configuration - Method not implemented
[Documentation] Test ID: 6.3.1.1.6
... Test title: PUT VNF Configuration - Method not implemented
... Test objective: The objective is to test that PUT method is not allowed to modify an existing VNF configuration
... Pre-conditions: none
... Reference: Clause 9.4.2.3.3 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VE
... Applicability: none
... Post-Conditions: none
Send PUT Request for VNF Configuration
Check HTTP Response Status Code Is 405
DELETE VNF Configuration - Method not implemented
[Documentation] Test ID: 6.3.1.1.7
... Test title: Delete VNF Configuration - Method not implemented
... Test objective: The objective is to test that DELETE method is not allowed to delete an existing VNF configuration
... Pre-conditions: none
... Reference: Clause 9.4.2.3.5 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VE
... Applicability: none
... Post-Conditions: none
Send DELETE Request for VNF Configuration
Check HTTP Response Status Code Is 405
*** Keywords ***
Get VNF configuration
Log Query VNF The GET method queries information about a configuration.
Set Headers {"Accept":"${ACCEPT}"}
Set Headers {"Content-Type": "${CONTENT_TYPE}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Log Execute Query and validate response
Get ${apiRoot}/${apiName}/${apiVersion}/configuration
${Etag}= Output response headers Etag
Log Validate Status code
Integer response status 200
${contentType}= Output response headers Content-Type
Should Contain ${contentType} ${CONTENT_TYPE}
${result}= Output response body
${json}= evaluate json.loads('''${result}''') json
Validate Json vnfConfiguration.schema.json ${json}
Log Validation OK
PUT Config - Method not implemented
log Trying to perform a PUT. This method should not be implemented
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Put ${apiRoot}/${apiName}/${apiVersion}/configuration
Log Validate Status code
Integer response status 405
Get ${apiRoot}/${apiName}/${apiMajorVersion}/configuration
${output}= Output response
Set Suite Variable ${response} ${output}
PATCH Config
log Trying to perform a PATCH. This method modifies the configuration
Send VNF configuration
log Trying to perform a PATCH. This method modifies the configuration
Set Headers {"Accept":"${ACCEPT}"}
Set Headers {"Content-Type": "${CONTENT_TYPE}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
${body}= Get File json/vnfConfigModifications.json
Patch ${apiRoot}/${apiName}/${apiVersion}/configuration ${body}
Log Validate Status code
${Etag_modified}= Output response headers Etag
Integer response status 200
${contentType}= Output response headers Content-Type
Should Contain ${contentType} ${CONTENT_TYPE}
${result}= Output response body
${json}= evaluate json.loads('''${result}''') json
Validate Json vnfConfigModifications.schema.json ${json}
Log Validation OK
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
${body}= Get File jsons/vnfConfigModifications.json
Patch ${apiRoot}/${apiName}/${apiMajorVersion}/configuration ${body}
${output}= Output response
Set Suite Variable ${response} ${output}
Check HTTP Response Status Code Is
[Arguments] ${expected_status}
Should Be Equal As Strings ${response['status']} ${expected_status}
Log Status code validated
PATCH Config - Precondition failed
[Documentation] Precondition Failed
... Precondition Failed A precondition given in an HTTP request header is not fulfilled.
... Typically, this is due to an ETag mismatch, indicating that the resource was modified by another entity.
... The response body should contain a ProblemDetails structure, in which the “detail” attribute should convey more information about the error.
Depends On Test PATCH Alarm # If the previous test scceeded, it means that Etag has been modified
Check HTTP Response Header Contains
[Arguments] ${CONTENT_TYPE}
Log ${response['headers']}
Should Contain ${response['headers']} ${CONTENT_TYPE}
Log Header is present
Check HTTP Response Body Json Schema Is
[Arguments] ${input}
Run Keyword If '${input}' == 'ProblemDetails' Should Contain ${response['headers']['Content-Type']} application/problem+json
... ELSE Should Contain ${response['headers']['Content-Type']} application/json
${schema}= Catenate SEPARATOR= ${input} .schema.json
Validate Json ${schema} ${response['body']}
Log Json Schema Validation OK
Check Postcondition VNF Configuration Unmodified (Implicit)
Log Check Implicit Postcondition
Check Postcondition VNF Is Configured
Check Postcondition VNF Is Configured
Log Check Postcondition for VNF Configuration
Get VNF configuration
${input_file}= Get File jsons/vnfConfigModifications.json
${input}= evaluate json.loads('''${input_file}''') json
Should Be Equal As Strings ${response['body']} ${input}
Send Duplicated VNF configuration
Depends On Test Send VNF configuration # If the previous test scceeded, it means that Etag has been modified
log Trying to perform a PATCH. This method modifies an individual alarm resource
Set Headers {"Accept":"${ACCEPT}"}
Set Headers {"Content-Type": "${CONTENT_TYPE}"}
Set Headers {"If-Match": "${Etag}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
${body}= Get File json/vnfConfigModifications.json
Patch ${apiRoot}/${apiName}/${apiVersion}/configuration ${body}
Log Validate Status code
Integer response status 412
${problemDetails}= Output response body
${json}= evaluate json.loads('''${problemDetails}''') json
Validate Json ProblemDetails.schema.json ${json}
Log Validation OK
Set Headers {"Accept":"${ACCEPT}"}
Set Headers {"Content-Type": "${CONTENT_TYPE}"}
Set Headers {"If-Match": "${etag}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
${body}= Get File jsons/vnfConfigModifications.json
Patch ${apiRoot}/${apiName}/${apiMajorVersion}/configuration ${body}
${output}= Output response
Set Suite Variable ${response} ${output}
DELETE Config - Method not implemented
log Trying to perform a DELETE. This method should not be implemented
Send POST Request for VNF Configuration
log Trying to perform a POST. This method should not be implemented
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Post ${apiRoot}/${apiName}/${apiMajorVersion}/configuration
${output}= Output response
Set Suite Variable ${response} ${output}
Send PUT Request for VNF Configuration
log Trying to perform a POST. This method should not be implemented
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Put ${apiRoot}/${apiName}/${apiMajorVersion}/configuration
${output}= Output response
Set Suite Variable ${response} ${output}
Send DELETE Request for VNF Configuration
log Trying to perform a POST. This method should not be implemented
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Delete ${apiRoot}/${apiName}/${apiVersion}/configuration
Log Validate Status code
Integer response status 405
\ No newline at end of file
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Delete ${apiRoot}/${apiName}/${apiMajorVersion}/configuration
${output}= Output response
Set Suite Variable ${response} ${output}
\ No newline at end of file
SOL002/VNFConfiguration-API/SOL002-VNFConfiguration-API.json deleted 100644 → 0
View file @ 4cff22f3
{
"swagger": "2.0",
"info": {
"version": "1.1.1",
"title": "SOL002 - VNF Configuration interface",
"description": "VNF Configuration interface of ETSI NFV SOL002\n\nIMPORTANT: Please note that this file might be not aligned to the current version of the ETSI Group Specification it refers to. In case of discrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/bugzilla/buglist.cgi?component=Nfv-Openapis&list_id=61&product=NFV&resolution=---\n",
"license": {
"name": "ETSI Forge copyright notice",
"url": "https://forge.etsi.org/etsi-forge-copyright-notice.txt"
}
},
"externalDocs": {
"description": "ETSI GS NFV-SOL 002 V2.4.1",
"url": "http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.04.01_60/gs_NFV-SOL002v020401p.pdf"
},
"basePath": "/vnfconfig/v1",
"schemes": [
"http",
"https"
],
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"paths": {
"/configuration": {
"get": {
"summary": "Read VNF/VNFC configuration from VNF.",
"description": "The client can use this method to read configuration information about a VNF instance and/or its VNFC instances.\n",
"responses": {
"200": {
"description": "OK\nConfiguration information about a VNF instance was read successfully. The response body shall contain a representation of the configuration resource.\n",
"schema": {
"$ref": "#/definitions/VnfConfiguration"
}
},
"400": {
"description": "Bad Request\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or a syntactically incorrect payload body), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\n ---\n\nIf the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n ---\n\nIf there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code.The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
},
"WWW-Authenticate": {
"description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
"type": "string",
"maximum": 1,
"minimum": 0
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
},
"401": {
"description": "Unauthorized\nIf the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
},
"WWW-Authenticate": {
"description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
"type": "string",
"maximum": 1,
"minimum": 0
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
},
"403": {
"description": "Forbidden\nIf the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided. It should include in the \"detail\" attribute information about the source of the problem, and may indicate how to solve it.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
},
"404": {
"description": "Not Found\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
},
"405": {
"description": "Method Not Allowed\nIf a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
},
"406": {
"description": "Not Acceptable\nIf the \"Accept\" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
},
"409": {
"description": "Conflict\nAnother request is in progress that prohibits the fulfilment of the current request, or the current resource state is inconsistent with the request.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
},
"416": {
"description": "Requested Range Not Satisfiable\nThis code is returned if the requested byte range in the Range HTTP header is not present in the requested resource.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
},
"422": {
"description": "Unprocessable Entity\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem. NOTE 2: This error response code is only applicable for methods that have a request body.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
},
"500": {
"description": "Internal Server Error\nIf there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond withthis response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
},
"503": {
"description": "Service Unavailable\nIf the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
}
}
},
"patch": {
"summary": "Modify VNF/VNFC configuration.",
"description": "This method sets or modifies a configuration resource.",
"parameters": [
{
"name": "configModifications",
"description": "The parameter for the configuration modification.",
"required": true,
"in": "body",
"schema": {
"$ref": "#/definitions/VnfConfigModifications"
}
}
],
"responses": {
"200": {
"description": "OK\nThe request was accepted and completed. The response body shall contain the parameters of the configuration modification that was applied to the configuration resource.\n",
"schema": {
"$ref": "#/definitions/VnfConfigModifications"
}
},
"400": {
"description": "Bad Request\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or a syntactically incorrect payload body), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\n ---\n\nIf the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n ---\n\nIf there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code.The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
},
"WWW-Authenticate": {
"description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
"type": "string",
"maximum": 1,
"minimum": 0
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
},
"401": {
"description": "Unauthorized\nIf the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
},
"WWW-Authenticate": {
"description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
"type": "string",
"maximum": 1,
"minimum": 0
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
},
"403": {
"description": "Forbidden\nIf the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided. It should include in the \"detail\" attribute information about the source of the problem, and may indicate how to solve it.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
},
"404": {
"description": "Not Found\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
},
"405": {
"description": "Method Not Allowed\nIf a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
},
"406": {
"description": "Not Acceptable\nIf the \"Accept\" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
},
"409": {
"description": "Conflict\nAnother request is in progress that prohibits the fulfilment of the current request, or the current resource state is inconsistent with the request.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
},
"412": {
"description": "Precondition Failed\nA precondition given in an HTTP request header is not fulfilled. Typically, this is due to an ETag mismatch, indicating that the resource was modified by another entity. The response body should contain a ProblemDetails structure, in which the \"detail\" attribute should convey more information about the error.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
},
"416": {
"description": "Requested Range Not Satisfiable\nThis code is returned if the requested byte range in the Range HTTP header is not present in the requested resource.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
},
"422": {
"description": "Unprocessable Entity\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem. NOTE 2: This error response code is only applicable for methods that have a request body.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
},
"500": {
"description": "Internal Server Error\nIf there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond withthis response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
},
"503": {
"description": "Service Unavailable\nIf the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "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\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "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).\n",
"type": "string"
},
"status": {
"description": "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.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
}
}
}
}
},
"definitions": {
"VnfConfiguration": {
"description": "This type represents configuration parameters of a VNF instance and its VNFC instances.\n",
"type": "object",
"required": [
"vnfConfigurationData"
],
"properties": {
"vnfConfigurationData": {
"description": "This type represents configuration parameters of a VNF instance.\n",
"type": "object",
"properties": {
"extCpConfig": {
"description": "This type represents configuration parameters of a CP instance.\n",
"type": "object",
"required": [
"cpId",
"cpdId",
"addresses"
],
"properties": {
"cpId": {
"description": "An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n",
"type": "string"
},
"cpdId": {
"description": "An identifier that is unique within a VNF descriptor.\n",
"type": "string"
},
"addresses": {
"description": "Network address and port assigned to the CP.\n",
"type": "array",
"items": {
"description": "This type represents configuration parameters of a CP instance address. * NOTE 1: Either \"address\" or \"useDynamicAddress\" shall be present.\n * NOTE 2: At least one of \"macAddress\" and \"ipAddress\" shall be present.\n",
"type": "object",
"properties": {
"address": {
"description": "Network address that has been configured on the CP. See NOTE 1.\n",
"type": "object",
"properties": {
"macAddress": {
"description": "A MAC address. Representation: string that consists of groups of two hexadecimal digits, separated by hyphens or colons.\n",
"type": "string",
"format": "MAC"
},
"ipAddress": {
"description": "An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons.\n",
"type": "string",
"format": "IP"
}
}
},
"useDynamicAddress": {
"description": "Set to true if an address shall be assigned dynamically. Otherwise set to false. The default value shall be false. See NOTE 1.\n",
"type": "boolean"
},
"port": {
"description": "The port assigned to the CP instance (e.g. IP port number, Ethernet port number, etc.).\n",
"type": "integer"
}
}
}
}
}
},
"dhcpServer": {
"description": "An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons.\n",
"type": "string",
"format": "IP"
},
"vnfSpecificData": {
"description": "This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.\n",
"type": "object"
}
}
},
"vnfcConfigurationData": {
"description": "Configuration parameters of the VNFC instances.\n",
"type": "array",
"items": {
"description": "This type represents configuration parameters of a VNFC instance.\n",
"type": "object",
"required": [
"vnfcInstanceId"
],
"properties": {
"vnfcInstanceId": {
"description": "An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n",
"type": "string"
},
"intCpConfig": {
"description": "Configuration parameters for the internal CPs of the VNFC instance.\n",
"type": "array",
"items": {
"description": "This type represents configuration parameters of a CP instance.\n",
"type": "object",
"required": [
"cpId",
"cpdId",
"addresses"
],
"properties": {
"cpId": {
"description": "An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n",
"type": "string"
},
"cpdId": {
"description": "An identifier that is unique within a VNF descriptor.\n",
"type": "string"
},
"addresses": {
"description": "Network address and port assigned to the CP.\n",
"type": "array",
"items": {
"description": "This type represents configuration parameters of a CP instance address. * NOTE 1: Either \"address\" or \"useDynamicAddress\" shall be present.\n * NOTE 2: At least one of \"macAddress\" and \"ipAddress\" shall be present.\n",
"type": "object",
"properties": {
"address": {
"description": "Network address that has been configured on the CP. See NOTE 1.\n",
"type": "object",
"properties": {
"macAddress": {
"description": "A MAC address. Representation: string that consists of groups of two hexadecimal digits, separated by hyphens or colons.\n",
"type": "string",
"format": "MAC"
},
"ipAddress": {
"description": "An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons.\n",
"type": "string",
"format": "IP"
}
}
},
"useDynamicAddress": {
"description": "Set to true if an address shall be assigned dynamically. Otherwise set to false. The default value shall be false. See NOTE 1.\n",
"type": "boolean"
},
"port": {
"description": "The port assigned to the CP instance (e.g. IP port number, Ethernet port number, etc.).\n",
"type": "integer"
}
}
}
}
}
}
},
"dhcpServer": {
"description": "An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons.\n",
"type": "string",
"format": "IP"
},
"vnfcSpecificData": {
"description": "This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.\n",
"type": "object"
}
}
}
}
}
},
"VnfConfigModifications": {
"description": "This type represents request parameters for the \"Set Configuration\" operation. * NOTE 1: At least one of \"vnfConfigurationData\" and \"vnfcConfigurationData\"\n shall be present.\n * NOTE 2: The VnfcConfiguration data type can only be used to modify the configuration\n of existing VNFC instances.\n",
"type": "object",
"properties": {
"vnfConfigurationData": {
"description": "This type represents configuration parameters of a VNF instance.\n",
"type": "object",
"properties": {
"extCpConfig": {
"description": "This type represents configuration parameters of a CP instance.\n",
"type": "object",
"required": [
"cpId",
"cpdId",
"addresses"
],
"properties": {
"cpId": {
"description": "An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n",
"type": "string"
},
"cpdId": {
"description": "An identifier that is unique within a VNF descriptor.\n",
"type": "string"
},
"addresses": {
"description": "Network address and port assigned to the CP.\n",
"type": "array",
"items": {
"description": "This type represents configuration parameters of a CP instance address. * NOTE 1: Either \"address\" or \"useDynamicAddress\" shall be present.\n * NOTE 2: At least one of \"macAddress\" and \"ipAddress\" shall be present.\n",
"type": "object",
"properties": {
"address": {
"description": "Network address that has been configured on the CP. See NOTE 1.\n",
"type": "object",
"properties": {
"macAddress": {
"description": "A MAC address. Representation: string that consists of groups of two hexadecimal digits, separated by hyphens or colons.\n",
"type": "string",
"format": "MAC"
},
"ipAddress": {
"description": "An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons.\n",
"type": "string",
"format": "IP"
}
}
},
"useDynamicAddress": {
"description": "Set to true if an address shall be assigned dynamically. Otherwise set to false. The default value shall be false. See NOTE 1.\n",
"type": "boolean"
},
"port": {
"description": "The port assigned to the CP instance (e.g. IP port number, Ethernet port number, etc.).\n",
"type": "integer"
}
}
}
}
}
},
"dhcpServer": {
"description": "An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons.\n",
"type": "string",
"format": "IP"
},
"vnfSpecificData": {
"description": "This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.\n",
"type": "object"
}
}
},
"vnfcConfigurationData": {
"description": "Modifications to configuration data for certain VNFC instances. See NOTE 1 and NOTE 2. If present, the modifications of the \"vnfcConfigurationData\" attribute shall follow these provisions: Modifying an attribute that is an array of objects of type \"VnfcConfigurationData\".\n Assumptions:\n 1) \"oldList\" is the \"VnfcConfigurationData\" array to be modified and \"newList\"\n is the \"VnfcConfigurationData\" array that contains the changes.\n 2) \"oldEntry\" is an entry in \"oldList\" and \"newEntry\" is an entry in \"newList\".\n 3) A \"newEntry\" has a \"corresponding entry\" if there exists an \"oldEntry\" that \n has the same content of the \"vnfcInstanceId\" attribute as the \"newEntry\"; \n a \"newEntry\" has no corresponding entry if no such \"oldEntry\" exists.\n 4) In any array of \"VnfcConfigurationData\" structures, the content of \"vnfcInstanceId\"\n is unique (i.e. there shall be no two entries with the same content of \"vnfcInstanceId\").\n Provisions:\n 1) For each \"newEntry\" in \"newList\" that has no corresponding entry in \"oldList\", \n the \"oldList\" array shall be modified by adding that \"newEntry\".\n\n 2) For each \"newEntry\" in \"newList\" that has a corresponding \"oldEntry\" in \"oldList\",\n the value of \"oldEntry\" shall be updated with the value of \"newEntry\" according to\n the rules of JSON Merge PATCH (see IETF RFC 7396 ).\n",
"type": "array",
"items": {
"description": "This type represents configuration parameters of a VNFC instance.\n",
"type": "object",
"required": [
"vnfcInstanceId"
],
"properties": {
"vnfcInstanceId": {
"description": "An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n",
"type": "string"
},
"intCpConfig": {
"description": "Configuration parameters for the internal CPs of the VNFC instance.\n",
"type": "array",
"items": {
"description": "This type represents configuration parameters of a CP instance.\n",
"type": "object",
"required": [
"cpId",
"cpdId",
"addresses"
],
"properties": {
"cpId": {
"description": "An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n",
"type": "string"
},
"cpdId": {
"description": "An identifier that is unique within a VNF descriptor.\n",
"type": "string"
},
"addresses": {
"description": "Network address and port assigned to the CP.\n",
"type": "array",
"items": {
"description": "This type represents configuration parameters of a CP instance address. * NOTE 1: Either \"address\" or \"useDynamicAddress\" shall be present.\n * NOTE 2: At least one of \"macAddress\" and \"ipAddress\" shall be present.\n",
"type": "object",
"properties": {
"address": {
"description": "Network address that has been configured on the CP. See NOTE 1.\n",
"type": "object",
"properties": {
"macAddress": {
"description": "A MAC address. Representation: string that consists of groups of two hexadecimal digits, separated by hyphens or colons.\n",
"type": "string",
"format": "MAC"
},
"ipAddress": {
"description": "An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons.\n",
"type": "string",
"format": "IP"
}
}
},
"useDynamicAddress": {
"description": "Set to true if an address shall be assigned dynamically. Otherwise set to false. The default value shall be false. See NOTE 1.\n",
"type": "boolean"
},
"port": {
"description": "The port assigned to the CP instance (e.g. IP port number, Ethernet port number, etc.).\n",
"type": "integer"
}
}
}
}
}
}
},
"dhcpServer": {
"description": "An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons.\n",
"type": "string",
"format": "IP"
},
"vnfcSpecificData": {
"description": "This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.\n",
"type": "object"
}
}
}
}
}
}
}
}
\ No newline at end of file
SOL002/VNFConfiguration-API/SOL002-VNFConfiguration-API.yaml deleted 100644 → 0
View file @ 4cff22f3
swagger: '2.0'
info:
version: 1.1.1
title: SOL002 - VNF Configuration interface
description: >
VNF Configuration interface of ETSI NFV SOL002
IMPORTANT: Please note that this file might be not aligned to the current
version of the ETSI Group Specification it refers to. In case of
discrepancies the published ETSI Group Specification takes precedence.
Please report bugs to
https://forge.etsi.org/bugzilla/buglist.cgi?component=Nfv-Openapis&list_id=61&product=NFV&resolution=---
license:
name: ETSI Forge copyright notice
url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt'
externalDocs:
description: ETSI GS NFV-SOL 002 V2.4.1
url: >-
http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.04.01_60/gs_NFV-SOL002v020401p.pdf
basePath: /vnfconfig/v1
schemes:
- http
- https
consumes:
- application/json
produces:
- application/json
paths:
/configuration:
get:
summary: Read VNF/VNFC configuration from VNF.
description: >
The client can use this method to read configuration information about a
VNF instance and/or its VNFC instances.
responses:
'200':
description: >
OK
Configuration information about a VNF instance was read
successfully. The response body shall contain a representation of
the configuration resource.
schema:
$ref: '#/definitions/VnfConfiguration'
'400':
description: >
Bad Request
If the request is malformed or syntactically incorrect (e.g. if the
request URI contains incorrect query parameters or a syntactically
incorrect payload body), the API producer shall respond with this
response code. The "ProblemDetails" structure shall be provided, and
should include in the "detail" attribute more information about the
source of the problem.
---
If the request contains a malformed access token, the API producer
should respond with this response. The details of the error shall be
returned in the WWW-Authenticate HTTP header, as defined in IETF RFC
6750 and IETF RFC 7235. The ProblemDetails structure may be
provided.
---
If there is an application error related to the client's input that
cannot be easily mapped to any other HTTP response code ("catch all
error"), the API producer shall respond with this response code.The
"ProblemDetails" structure shall be provided, and shall include in
the "detail" attribute more information about the source of the
problem.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
WWW-Authenticate:
description: >
Challenge if the corresponding HTTP request has not provided
authorization, or error details if the corresponding HTTP
request has provided an invalid authorization token.
type: string
maximum: 1
minimum: 0
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
'401':
description: >
Unauthorized
If the request contains no access token even though one is required,
or if the request contains an authorization token that is invalid
(e.g. expired or revoked), the API producer should respond with this
response. The details of the error shall be returned in the
WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
RFC 7235. The ProblemDetails structure may be provided.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
WWW-Authenticate:
description: >
Challenge if the corresponding HTTP request has not provided
authorization, or error details if the corresponding HTTP
request has provided an invalid authorization token.
type: string
maximum: 1
minimum: 0
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
'403':
description: >
Forbidden
If the API consumer is not allowed to perform a particular request
to a particular resource, the API producer shall respond with this
response code. The "ProblemDetails" structure shall be provided. It
should include in the "detail" attribute information about the
source of the problem, and may indicate how to solve it.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
'404':
description: >
Not Found
If the API producer did not find a current representation for the
resource addressed by the URI passed in the request, or is not
willing to disclose that one exists, it shall respond with this
response code. The "ProblemDetails" structure may be provided,
including in the "detail" attribute information about the source of
the problem, e.g. a wrong resource URI variable.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
'405':
description: >
Method Not Allowed
If a particular HTTP method is not supported for a particular
resource, the API producer shall respond with this response code.
The "ProblemDetails" structure may be omitted in that case.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
'406':
description: >
Not Acceptable
If the "Accept" HTTP header does not contain at least one name of a
content type that is acceptable to the API producer, the API
producer shall respond with this response code. The "ProblemDetails"
structure may be omitted in that case.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
'409':
description: >
Conflict
Another request is in progress that prohibits the fulfilment of the
current request, or the current resource state is inconsistent with
the request.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
'416':
description: >
Requested Range Not Satisfiable
This code is returned if the requested byte range in the Range HTTP
header is not present in the requested resource.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
'422':
description: >
Unprocessable Entity
If the payload body of a request contains syntactically correct data
(e.g. well-formed JSON) but the data cannot be processed (e.g.
because it fails validation against a schema), the API producer
shall respond with this response code. The "ProblemDetails"
structure shall be provided, and should include in the "detail"
attribute more information about the source of the problem. NOTE 2:
This error response code is only applicable for methods that have a
request body.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
'500':
description: >
Internal Server Error
If there is an application error not related to the client's input
that cannot be easily mapped to any other HTTP response code ("catch
all error"), the API producer shall respond withthis response code.
The "ProblemDetails" structure shall be provided, and shall include
in the "detail" attribute more information about the source of the
problem.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
'503':
description: >
Service Unavailable
If the API producer encounters an internal overload situation of
itself or of a system it relies on, it should respond with this
response code, following the provisions in IETF RFC 7231 [13] for
the use of the "Retry-After" HTTP header and for the alternative to
refuse the connection. The "ProblemDetails" structure may be
omitted.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
patch:
summary: Modify VNF/VNFC configuration.
description: This method sets or modifies a configuration resource.
parameters:
- name: configModifications
description: The parameter for the configuration modification.
required: true
in: body
schema:
$ref: '#/definitions/VnfConfigModifications'
responses:
'200':
description: >
OK
The request was accepted and completed. The response body shall
contain the parameters of the configuration modification that was
applied to the configuration resource.
schema:
$ref: '#/definitions/VnfConfigModifications'
'400':
description: >
Bad Request
If the request is malformed or syntactically incorrect (e.g. if the
request URI contains incorrect query parameters or a syntactically
incorrect payload body), the API producer shall respond with this
response code. The "ProblemDetails" structure shall be provided, and
should include in the "detail" attribute more information about the
source of the problem.
---
If the request contains a malformed access token, the API producer
should respond with this response. The details of the error shall be
returned in the WWW-Authenticate HTTP header, as defined in IETF RFC
6750 and IETF RFC 7235. The ProblemDetails structure may be
provided.
---
If there is an application error related to the client's input that
cannot be easily mapped to any other HTTP response code ("catch all
error"), the API producer shall respond with this response code.The
"ProblemDetails" structure shall be provided, and shall include in
the "detail" attribute more information about the source of the
problem.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
WWW-Authenticate:
description: >
Challenge if the corresponding HTTP request has not provided
authorization, or error details if the corresponding HTTP
request has provided an invalid authorization token.
type: string
maximum: 1
minimum: 0
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
'401':
description: >
Unauthorized
If the request contains no access token even though one is required,
or if the request contains an authorization token that is invalid
(e.g. expired or revoked), the API producer should respond with this
response. The details of the error shall be returned in the
WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
RFC 7235. The ProblemDetails structure may be provided.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
WWW-Authenticate:
description: >
Challenge if the corresponding HTTP request has not provided
authorization, or error details if the corresponding HTTP
request has provided an invalid authorization token.
type: string
maximum: 1
minimum: 0
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
'403':
description: >
Forbidden
If the API consumer is not allowed to perform a particular request
to a particular resource, the API producer shall respond with this
response code. The "ProblemDetails" structure shall be provided. It
should include in the "detail" attribute information about the
source of the problem, and may indicate how to solve it.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
'404':
description: >
Not Found
If the API producer did not find a current representation for the
resource addressed by the URI passed in the request, or is not
willing to disclose that one exists, it shall respond with this
response code. The "ProblemDetails" structure may be provided,
including in the "detail" attribute information about the source of
the problem, e.g. a wrong resource URI variable.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
'405':
description: >
Method Not Allowed
If a particular HTTP method is not supported for a particular
resource, the API producer shall respond with this response code.
The "ProblemDetails" structure may be omitted in that case.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
'406':
description: >
Not Acceptable
If the "Accept" HTTP header does not contain at least one name of a
content type that is acceptable to the API producer, the API
producer shall respond with this response code. The "ProblemDetails"
structure may be omitted in that case.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
'409':
description: >
Conflict
Another request is in progress that prohibits the fulfilment of the
current request, or the current resource state is inconsistent with
the request.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
'412':
description: >
Precondition Failed
A precondition given in an HTTP request header is not fulfilled.
Typically, this is due to an ETag mismatch, indicating that the
resource was modified by another entity. The response body should
contain a ProblemDetails structure, in which the "detail" attribute
should convey more information about the error.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
'416':
description: >
Requested Range Not Satisfiable
This code is returned if the requested byte range in the Range HTTP
header is not present in the requested resource.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
'422':
description: >
Unprocessable Entity
If the payload body of a request contains syntactically correct data
(e.g. well-formed JSON) but the data cannot be processed (e.g.
because it fails validation against a schema), the API producer
shall respond with this response code. The "ProblemDetails"
structure shall be provided, and should include in the "detail"
attribute more information about the source of the problem. NOTE 2:
This error response code is only applicable for methods that have a
request body.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
'500':
description: >
Internal Server Error
If there is an application error not related to the client's input
that cannot be easily mapped to any other HTTP response code ("catch
all error"), the API producer shall respond withthis response code.
The "ProblemDetails" structure shall be provided, and shall include
in the "detail" attribute more information about the source of the
problem.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
'503':
description: >
Service Unavailable
If the API producer encounters an internal overload situation of
itself or of a system it relies on, it should respond with this
response code, following the provisions in IETF RFC 7231 [13] for
the use of the "Retry-After" HTTP header and for the alternative to
refuse the connection. The "ProblemDetails" structure may be
omitted.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
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".
type: string
format: URI
title:
description: >
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).
type: string
status:
description: >
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.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
definitions:
VnfConfiguration:
description: >
This type represents configuration parameters of a VNF instance and its
VNFC instances.
type: object
required:
- vnfConfigurationData
properties:
vnfConfigurationData:
description: |
This type represents configuration parameters of a VNF instance.
type: object
properties:
extCpConfig:
description: |
This type represents configuration parameters of a CP instance.
type: object
required:
- cpId
- cpdId
- addresses
properties:
cpId:
description: >
An identifier that is unique for the respective type within a
VNF instance, but may not be globally unique.
type: string
cpdId:
description: |
An identifier that is unique within a VNF descriptor.
type: string
addresses:
description: |
Network address and port assigned to the CP.
type: array
items:
description: >
This type represents configuration parameters of a CP
instance address.
* NOTE 1: Either "address" or "useDynamicAddress" shall be present.
* NOTE 2: At least one of "macAddress" and "ipAddress" shall be present.
type: object
properties:
address:
description: >
Network address that has been configured on the CP. See
NOTE 1.
type: object
properties:
macAddress:
description: >
A MAC address. Representation: string that consists
of groups of two hexadecimal digits, separated by
hyphens or colons.
type: string
format: MAC
ipAddress:
description: >
An IPV4 or IPV6 address. Representation: In case of
an IPV4 address, string that consists of four
decimal integers separated by dots, each integer
ranging from 0 to 255. In case of an IPV6 address,
string that consists of groups of zero to four
hexadecimal digits, separated by colons.
type: string
format: IP
useDynamicAddress:
description: >
Set to true if an address shall be assigned dynamically.
Otherwise set to false. The default value shall be
false. See NOTE 1.
type: boolean
port:
description: >
The port assigned to the CP instance (e.g. IP port
number, Ethernet port number, etc.).
type: integer
dhcpServer:
description: >
An IPV4 or IPV6 address. Representation: In case of an IPV4
address, string that consists of four decimal integers separated
by dots, each integer ranging from 0 to 255. In case of an IPV6
address, string that consists of groups of zero to four
hexadecimal digits, separated by colons.
type: string
format: IP
vnfSpecificData:
description: >
This type represents a list of key-value pairs. The order of the
pairs in the list is not significant. In JSON, a set of key- value
pairs is represented as an object. It shall comply with the
provisions defined in clause 4 of IETF RFC 7159.
type: object
vnfcConfigurationData:
description: |
Configuration parameters of the VNFC instances.
type: array
items:
description: |
This type represents configuration parameters of a VNFC instance.
type: object
required:
- vnfcInstanceId
properties:
vnfcInstanceId:
description: >
An identifier that is unique for the respective type within a
VNF instance, but may not be globally unique.
type: string
intCpConfig:
description: >
Configuration parameters for the internal CPs of the VNFC
instance.
type: array
items:
description: >
This type represents configuration parameters of a CP
instance.
type: object
required:
- cpId
- cpdId
- addresses
properties:
cpId:
description: >
An identifier that is unique for the respective type
within a VNF instance, but may not be globally unique.
type: string
cpdId:
description: |
An identifier that is unique within a VNF descriptor.
type: string
addresses:
description: |
Network address and port assigned to the CP.
type: array
items:
description: >
This type represents configuration parameters of a CP
instance address.
* NOTE 1: Either "address" or "useDynamicAddress" shall be present.
* NOTE 2: At least one of "macAddress" and "ipAddress" shall be present.
type: object
properties:
address:
description: >
Network address that has been configured on the CP.
See NOTE 1.
type: object
properties:
macAddress:
description: >
A MAC address. Representation: string that
consists of groups of two hexadecimal digits,
separated by hyphens or colons.
type: string
format: MAC
ipAddress:
description: >
An IPV4 or IPV6 address. Representation: In case
of an IPV4 address, string that consists of four
decimal integers separated by dots, each integer
ranging from 0 to 255. In case of an IPV6
address, string that consists of groups of zero
to four hexadecimal digits, separated by colons.
type: string
format: IP
useDynamicAddress:
description: >
Set to true if an address shall be assigned
dynamically. Otherwise set to false. The default
value shall be false. See NOTE 1.
type: boolean
port:
description: >
The port assigned to the CP instance (e.g. IP port
number, Ethernet port number, etc.).
type: integer
dhcpServer:
description: >
An IPV4 or IPV6 address. Representation: In case of an IPV4
address, string that consists of four decimal integers separated
by dots, each integer ranging from 0 to 255. In case of an IPV6
address, string that consists of groups of zero to four
hexadecimal digits, separated by colons.
type: string
format: IP
vnfcSpecificData:
description: >
This type represents a list of key-value pairs. The order of the
pairs in the list is not significant. In JSON, a set of key-
value pairs is represented as an object. It shall comply with
the provisions defined in clause 4 of IETF RFC 7159.
type: object
VnfConfigModifications:
description: >
This type represents request parameters for the "Set Configuration"
operation.
* NOTE 1: At least one of "vnfConfigurationData" and "vnfcConfigurationData"
shall be present.
* NOTE 2: The VnfcConfiguration data type can only be used to modify the configuration
of existing VNFC instances.
type: object
properties:
vnfConfigurationData:
description: |
This type represents configuration parameters of a VNF instance.
type: object
properties:
extCpConfig:
description: |
This type represents configuration parameters of a CP instance.
type: object
required:
- cpId
- cpdId
- addresses
properties:
cpId:
description: >
An identifier that is unique for the respective type within a
VNF instance, but may not be globally unique.
type: string
cpdId:
description: |
An identifier that is unique within a VNF descriptor.
type: string
addresses:
description: |
Network address and port assigned to the CP.
type: array
items:
description: >
This type represents configuration parameters of a CP
instance address.
* NOTE 1: Either "address" or "useDynamicAddress" shall be present.
* NOTE 2: At least one of "macAddress" and "ipAddress" shall be present.
type: object
properties:
address:
description: >
Network address that has been configured on the CP. See
NOTE 1.
type: object
properties:
macAddress:
description: >
A MAC address. Representation: string that consists
of groups of two hexadecimal digits, separated by
hyphens or colons.
type: string
format: MAC
ipAddress:
description: >
An IPV4 or IPV6 address. Representation: In case of
an IPV4 address, string that consists of four
decimal integers separated by dots, each integer
ranging from 0 to 255. In case of an IPV6 address,
string that consists of groups of zero to four
hexadecimal digits, separated by colons.
type: string
format: IP
useDynamicAddress:
description: >
Set to true if an address shall be assigned dynamically.
Otherwise set to false. The default value shall be
false. See NOTE 1.
type: boolean
port:
description: >
The port assigned to the CP instance (e.g. IP port
number, Ethernet port number, etc.).
type: integer
dhcpServer:
description: >
An IPV4 or IPV6 address. Representation: In case of an IPV4
address, string that consists of four decimal integers separated
by dots, each integer ranging from 0 to 255. In case of an IPV6
address, string that consists of groups of zero to four
hexadecimal digits, separated by colons.
type: string
format: IP
vnfSpecificData:
description: >
This type represents a list of key-value pairs. The order of the
pairs in the list is not significant. In JSON, a set of key- value
pairs is represented as an object. It shall comply with the
provisions defined in clause 4 of IETF RFC 7159.
type: object
vnfcConfigurationData:
description: >
Modifications to configuration data for certain VNFC instances. See
NOTE 1 and NOTE 2. If present, the modifications of the
"vnfcConfigurationData" attribute shall follow these provisions:
Modifying an attribute that is an array of objects of type "VnfcConfigurationData".
Assumptions:
1) "oldList" is the "VnfcConfigurationData" array to be modified and "newList"
is the "VnfcConfigurationData" array that contains the changes.
2) "oldEntry" is an entry in "oldList" and "newEntry" is an entry in "newList".
3) A "newEntry" has a "corresponding entry" if there exists an "oldEntry" that
has the same content of the "vnfcInstanceId" attribute as the "newEntry";
a "newEntry" has no corresponding entry if no such "oldEntry" exists.
4) In any array of "VnfcConfigurationData" structures, the content of "vnfcInstanceId"
is unique (i.e. there shall be no two entries with the same content of "vnfcInstanceId").
Provisions:
1) For each "newEntry" in "newList" that has no corresponding entry in "oldList",
the "oldList" array shall be modified by adding that "newEntry".
2) For each "newEntry" in "newList" that has a corresponding "oldEntry" in "oldList",
the value of "oldEntry" shall be updated with the value of "newEntry" according to
the rules of JSON Merge PATCH (see IETF RFC 7396 ).
type: array
items:
description: |
This type represents configuration parameters of a VNFC instance.
type: object
required:
- vnfcInstanceId
properties:
vnfcInstanceId:
description: >
An identifier that is unique for the respective type within a
VNF instance, but may not be globally unique.
type: string
intCpConfig:
description: >
Configuration parameters for the internal CPs of the VNFC
instance.
type: array
items:
description: >
This type represents configuration parameters of a CP
instance.
type: object
required:
- cpId
- cpdId
- addresses
properties:
cpId:
description: >
An identifier that is unique for the respective type
within a VNF instance, but may not be globally unique.
type: string
cpdId:
description: |
An identifier that is unique within a VNF descriptor.
type: string
addresses:
description: |
Network address and port assigned to the CP.
type: array
items:
description: >
This type represents configuration parameters of a CP
instance address.
* NOTE 1: Either "address" or "useDynamicAddress" shall be present.
* NOTE 2: At least one of "macAddress" and "ipAddress" shall be present.
type: object
properties:
address:
description: >
Network address that has been configured on the CP.
See NOTE 1.
type: object
properties:
macAddress:
description: >
A MAC address. Representation: string that
consists of groups of two hexadecimal digits,
separated by hyphens or colons.
type: string
format: MAC
ipAddress:
description: >
An IPV4 or IPV6 address. Representation: In case
of an IPV4 address, string that consists of four
decimal integers separated by dots, each integer
ranging from 0 to 255. In case of an IPV6
address, string that consists of groups of zero
to four hexadecimal digits, separated by colons.
type: string
format: IP
useDynamicAddress:
description: >
Set to true if an address shall be assigned
dynamically. Otherwise set to false. The default
value shall be false. See NOTE 1.
type: boolean
port:
description: >
The port assigned to the CP instance (e.g. IP port
number, Ethernet port number, etc.).
type: integer
dhcpServer:
description: >
An IPV4 or IPV6 address. Representation: In case of an IPV4
address, string that consists of four decimal integers separated
by dots, each integer ranging from 0 to 255. In case of an IPV6
address, string that consists of groups of zero to four
hexadecimal digits, separated by colons.
type: string
format: IP
vnfcSpecificData:
description: >
This type represents a list of key-value pairs. The order of the
pairs in the list is not significant. In JSON, a set of key-
value pairs is represented as an object. It shall comply with
the provisions defined in clause 4 of IETF RFC 7159.
type: object
SOL002/VNFConfiguration-API/environment/variables.txt
View file @ 132ae1a2
*** Variables ***
${VNFM_HOST} localhost # Hostname of the VNFM
${VNFM_PORT} 8080 # Listening port of the VNFM
${VNF_HOST} localhost # Hostname of the NFVO
${VNF_PORT} 8081 # Listening port of the NFVO
${VNFM_SCHEMA} https
${VNF_SCHEMA} https
${AUTHORIZATION} Bearer QWxhZGRpbjpvcGVuIHNlc2FtZQ==
${CONTENT_TYPE} application/json
${CONTENT_TYPE_PATCH} application/merge-patch+json
${Etag} an etag
${Etag_modified} 12345
${response}= httpresponse
${EM-VNF_HOST} localhost # Hostname of the NFVO
${EM-VNF_PORT} 8081 # Listening port of the NFVO
${EM-VNF_SCHEMA} https
${ACCEPT} application/json
${AUTH_USAGE} 1
${AUTHORIZATION_HEADER} Authorization
${AUTHORIZATION_TOKEN} Bearer 0b79bab50daca910b000d4f1a2b675d604257e42
${CONTENT_TYPE} application/json
${apiRoot} /
${apiName} vnfconfig
${apiVersion} v1
${AUTH_USAGE} 1
${WRONG_AUTHORIZATION} Bearer XXXXXWRONGXXXXX
${alarm_filter} managedObjectId
${managedObjectId} 007c111c-38a1-42c0-a666-7475ecb1567c
${invalid_alarm_filter} badFilter
${alarmId} 6fc3539c-e602-4afa-8e13-962fb5a7d81d
${vnfInstanceDescription} description vnf
${vnfInstanceDescription_Update} Updated description vnf
${SINGLE_FILE_VNFD} 1 # If VNFD is PLAIN TEXT
${ACCEPT_PLAIN} text/plain
${ACCEPT_ZIP} application/zip
${vnfPkgId_processing} 007c111c-38a1-42c0-a666-7475ecb1567c
${ARTIFACT_TYPE} application/octet-stream
${ARTIFACT_ID} artifactId
${WRONG_ACCEPT} application/json
${vnfLcmOpOccId} 6fc3539c-e602-4afa-8e13-962fb5a7d81d
${CancelMode} GRACEFUL
${LccnSubscriptionRequest} {}
${NVFM_DUPLICATION} 0
${sub_filter} filter
${sub_filter_invalid} filter_invalid
${subscriptionId} 6fc3539c-e602-4afa-8e13-962fb5a7d81f
${notification_ep} /notification
${notification_port} 9091
${AlarmNotification} {}
${AlarmClearedNotification} {}
${AlarmListRebuiltNotification} {}
${PerceivedSeverity} CRITICAL
\ No newline at end of file
${apiMajorVersion} v1
${WRONG_AUTHORIZATION} Bearer XXXXXWRONGXXXXX
\ No newline at end of file
SOL002/VNFConfiguration-API/jsons/vnfConfigModifications.json
View file @ 132ae1a2
......@@ -39,5 +39,6 @@
"dhcpServer": "string",
"vnfcSpecificData": {}
}
]
],
"vnfcConfigurationDataDeleteIds": []
}
\ No newline at end of file
SOL002/VNFConfiguration-API/schemas/ApiVersionInformation.schema.json 0 → 100644
View file @ 132ae1a2
{
"description": "This type represents API version information.\n",
"type": "object",
"required": [
"uriPrefix",
"apiVersions"
],
"properties": {
"uriPrefix": {
"description": "Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n",
"type": "string"
},
"apiVersions": {
"description": "Version(s) supported for the API signaled by the uriPrefix attribute.\n",
"type": "array",
"items": {
"type": "object",
"required": [
"version"
],
"properties": {
"version": {
"description": "Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n",
"type": "string"
},
"isDeprecated": {
"description": "If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n",
"type": "boolean"
},
"retirementDate": {
"description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n",
"type": "string",
"format": "date-time"
}
}
}
}
}
}
\ No newline at end of file
SOL002/VNFFaultManagement-API/Alarms.robot
View file @ 132ae1a2
*** Settings ***
# Suite setup Expect spec SOL003-VNFLifecycleManagement-API.yaml
Resource environment/variables.txt
Library REST ${VNFM_SCHEMA}://${VNFM_HOST}:${VNFM_PORT}
... spec=SOL002-VNFFaultManagement-API.yaml
Library REST ${VNFM_SCHEMA}://${VNFM_HOST}:${VNFM_PORT} ssl_verify=false
Library JSONLibrary
Library JSONSchemaLibrary schemas/
Library OperatingSystem
Library Collections
*** Test cases ***
*** Test Cases ***
POST Alarms - Method not implemented
log Trying to perform a PUT. This method should not be implemented
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Post ${apiRoot}/${apiName}/${apiVersion}/alarms
Log Validate Status code
Integer response status 405
[Documentation] Test ID: 6.3.4.1.1
... Test title: POST Alarms - Method not implemented
... Test objective: The objective is to test that the method is not implemented
... Pre-conditions: none
... Reference: Clause 7.4.2.3.1 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
POST Alarms Task
Check HTTP Response Status Code Is 405
Get information about multiple alarms
Log Query VNF The GET method queries information about multiple alarms.
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Log Execute Query and validate response
Get ${apiRoot}/${apiName}/${apiVersion}/alarms
Log Validate Status code
Integer response status 200
${contentType}= Output response headers Content-Type
Should Contain ${contentType} ${CONTENT_TYPE}
${result}= Output response body
${json}= evaluate json.loads('''${result}''') json
Validate Json alarm.schema.json ${json}
Log Validation OK
GET information about multiple alarms
[Documentation] Test ID: 6.3.4.1.2
... Test title: GET information about multiple alarms
... Test objective: The objective is to retrieve information about the alarm list
... Pre-conditions: none
... Reference: Clause 7.4.2.3.2 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
GET Alarms Task
Check HTTP Response Status Code Is 200
Check HTTP Response Body Json Schema Is alarms
Get information about multiple alarms with filters
Log Query VNF The GET method queries information about multiple alarms with filters.
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Log Execute Query and validate response
Get ${apiRoot}/${apiName}/${apiVersion}/alarms?${alarm_filter}=${managedObjectId}
Log Validate Status code
Integer response status 200
${contentType}= Output response headers Content-Type
Should Contain ${contentType} ${CONTENT_TYPE}
${result}= Output response body
${json}= evaluate json.loads('''${result}''') json
Validate Json alarm.schema.json ${json}
Log Validation OK
GET information about multiple alarms with attribute-based filter
[Documentation] Test ID: 6.3.4.1.3
... Test title: GET information about multiple alarms with attribute-based filter
... Test objective: The objective is to retrieve information about the alarm list with attribute-based filter
... Pre-conditions: none
... Reference: Clause 7.4.2.3.2 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
GET Alarms Task with filter
Check HTTP Response Status Code Is 200
Check HTTP Response Body Json Schema Is alarms
GET information about multiple alarms with invalid attribute-based filter
[Documentation] Test ID: 6.3.4.1.4
... Test title: GET information about multiple alarms with invalid attribute-based filter
... Test objective: The objective is to retrieve information about the alarm list
... Pre-conditions: none
... Reference: Clause 7.4.2.3.2 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
GET Alarms Task with invalid filter
Check HTTP Response Status Code Is 400
Check HTTP Response Body Json Schema Is ProblemDetails
Get information about multiple alarms Bad Request Invalid attribute-based filtering parameters
Log Query VNF The GET method queries information about multiple alarm instances.
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Get ${apiRoot}/${apiName}/${apiVersion}/alarms?${invalid_alarm_filter}=${managedObjectId}
Log Validate Status code
Integer response status 400
${problemDetails}= Output response body
${json}= evaluate json.loads('''${problemDetails}''') json
Validate Json ProblemDetails.schema.json ${json}
Log Validation OK
GET information about multiple alarms with "all_fields" attribute selector
[Documentation] Test ID: 6.3.4.1.5
... Test title: GET information about multiple alarms with "all_fields" attribute selector
... Test objective: The objective is to retrieve information about the alarm list
... Pre-conditions: none
... Reference: Clause 7.4.2.3.3 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
GET Alarms Task with all_fields attribute selector
Check HTTP Response Status Code Is 200
Check HTTP Response Body Json Schema Is alarms
GET information about multiple alarms with exclude_default attribute selector
[Documentation] Test ID: 6.3.4.1.6
... Test title: GET information about multiple alarms with "exclude_default" attribute selector
... Test objective: The objective is to retrieve information about the alarm list
... Pre-conditions: none
... Reference: Clause 7.4.2.3.3 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
GET Alarms Task with exclude_default attribute selector
Check HTTP Response Status Code Is 200
Check HTTP Response Body Json Schema Is alarms
GET information about multiple alarms with fields attribute selector
[Documentation] Test ID: 6.3.4.1.7
... Test title: GET information about multiple alarms with fields attribute selector
... Test objective: The objective is to retrieve information about the alarm list
... Pre-conditions: none
... Reference: Clause 7.4.2.3.3 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
GET Alarms Task with fields attribute selector
Check HTTP Response Status Code Is 200
Check HTTP Response Body Json Schema Is alarms
GET information about multiple alarms with "exclude_fields" attribute selector
[Documentation] Test ID: 6.3.4.1.8
... Test title: GET information about multiple alarms with "exclude_fields" attribute selector
... Test objective: The objective is to retrieve information about the alarm list
... Pre-conditions: none
... Reference: Clause 7.4.2.3.3 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
GET Alarms Task with exclude_fields attribute selector
Check HTTP Response Status Code Is 200
Check HTTP Response Body Json Schema Is alarms
PUT Alarms - Method not implemented
log Trying to perform a PUT. This method should not be implemented
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Put ${apiRoot}/${apiName}/${apiVersion}/alarms
Log Validate Status code
Integer response status 405
[Documentation] Test ID: 6.3.4.1.9
... Test title: PUT Alarms - Method not implemented
... Test objective: The objective is to test that the method is not implemented
... Pre-conditions: none
... Reference: Clause 7.4.2.3.3 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
PUT Alarms Task
Check HTTP Response Status Code Is 405
PATCH Alarms - Method not implemented
log Trying to perform a PATCH. This method should not be implemented
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Patch ${apiRoot}/${apiName}/${apiVersion}/alarms
Log Validate Status code
Integer response status 405
[Documentation] Test ID: 6.3.4.1.10
... Test title: PATCH Alarms - Method not implemented
... Test objective: The objective is to test that the method is not implemented
... Pre-conditions: none
... Reference: Clause 7.4.2.3.4 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
PATCH Alarms Task
Check HTTP Response Status Code Is 405
DELETE Alarms - Method not implemented
[Documentation] Test ID: 6.3.4.1.11
... Test title: DELETE Alarms - Method not implemented
... Test objective: The objective is to test that the method is not implemented
... Pre-conditions: none
... Reference: Clause 7.4.2.3.5 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
DELETE Alarms Task
Check HTTP Response Status Code Is 405
GET information about multiple alarms to get Paged Response
[Documentation] Test ID: 6.3.4.1.12
... Test title: GET information about multiple alarms to get Paged Response
... Test objective: The objective is to retrieve information about the alarms to get paged response
... Pre-conditions: none
... Reference: Clause 7.4.2.3.2 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
GET Alarms Task
Check HTTP Response Status Code Is 200
Check HTTP Response Header Contain Link
GET information about multiple alarms for Bad Request Response too big
[Documentation] Test ID: 6.3.4.1.13
... Test title: GET information about multiple alarms for Bad Request Response too big
... Test objective: The objective is to test that GET method fail retrieving status information about Alarms when Response is too big, and perform the JSON schema validation of the failed operation HTTP response
... Pre-conditions: none
... Reference: Clause 7.4.2.3.2 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
GET Alarms Task with invalid filter
Check HTTP Response Status Code Is 400
Check HTTP Response Body Json Schema Is ProblemDetails
GET information about alarms with attribute-based filter "id"
[Documentation] Test ID: 6.3.4.1.14
... Test title: GET information about alarms with attribute-based filter "id"
... Test objective: The objective is to retrieve information about the alarm list with alarm filter "id"
... Pre-conditions: none
... Reference: Clause 7.4.2.3.2 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
GET Alarms Task with filter "id"
Check HTTP Response Status Code Is 200
Check HTTP Response Body Json Schema Is alarm
Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "id"
GET information about multiple alarms with attribute-based filter "vnfcInstanceIds"
[Documentation] Test ID: 6.3.4.1.15
... Test title: GET information about multiple alarms with attribute-based filter "vnfcInstanceIds"
... Test objective: The objective is to retrieve information about the alarm list with attribute filter "vnfcInstanceIds"
... Pre-conditions: none
... Reference: Clause 7.4.2.3.2 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
GET Alarms Task with filter "vnfcInstanceIds"
Check HTTP Response Status Code Is 200
Check HTTP Response Body Json Schema Is alarms
Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "vnfcInstanceIds"
GET information about multiple alarms with attribute-based filter "rootCauseFaultyResource.faultyResourceType"
[Documentation] Test ID: 6.3.4.1.16
... Test title: GET information about multiple alarms with attribute-based filter "rootCauseFaultyResource.faultyResourceType"
... Test objective: The objective is to retrieve information about the alarm list with attribute filter "rootCauseFaultyResource.faultyResourceType"
... Pre-conditions: none
... Reference: Clause 7.4.2.3.2 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
GET Alarms Task with filter "rootCauseFaultyResource_faultyResourceType"
Check HTTP Response Status Code Is 200
Check HTTP Response Body Json Schema Is alarms
Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "rootCauseFaultyResource_faultyResourceType"
GET information about multiple alarms with attribute-based filter "eventType"
[Documentation] Test ID: 6.3.4.1.17
... Test title: GET information about multiple alarms with attribute-based filter "eventType"
... Test objective: The objective is to retrieve information about the alarm list with attribute filter "eventType"
... Pre-conditions: none
... Reference: Clause 7.4.2.3.2 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
GET Alarms Task with filter "eventType"
Check HTTP Response Status Code Is 200
Check HTTP Response Body Json Schema Is alarms
Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "eventType"
GET information about multiple alarms with attribute-based filter "perceivedSeverity"
[Documentation] Test ID: 6.3.4.1.18
... Test title: GET information about multiple alarms with attribute-based filter "perceivedSeverity"
... Test objective: The objective is to retrieve information about the alarm list with attribute filter "perceivedSeverity"
... Pre-conditions: none
... Reference: Clause 7.4.2.3.2 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
GET Alarms Task with filter "perceivedSeverity"
Check HTTP Response Status Code Is 200
Check HTTP Response Body Json Schema Is alarms
Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "perceivedSeverity"
GET information about multiple alarms with attribute-based filter "probableCause"
[Documentation] Test ID: 6.3.4.1.19
... Test title: GET information about multiple alarms with attribute-based filter "probableCause"
... Test objective: The objective is to retrieve information about the alarm list with attribute filter "probableCause"
... Pre-conditions: none
... Reference: Clause 7.4.2.3.2 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
GET Alarms Task with filter "probableCause"
Check HTTP Response Status Code Is 200
Check HTTP Response Body Json Schema Is alarms
Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "probableCause"
*** Keywords ***
POST Alarms Task
log Trying to perform a POST. This method should not be implemented
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Post ${apiRoot}/${apiName}/${apiMajorVersion}/alarms
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
PUT Alarms Task
log Trying to perform a PUT. This method should not be implemented
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Put ${apiRoot}/${apiName}/${apiMajorVersion}/alarms
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
PATCH Alarms Task
log Trying to perform a PATCH. This method should not be implemented
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Patch ${apiRoot}/${apiName}/${apiMajorVersion}/alarms
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
DELETE Alarms Task
log Trying to perform a DELETE. This method should not be implemented
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Delete ${apiRoot}/${apiName}/${apiVersion}/alarms
Log Validate Status code
Integer response status 405
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Delete ${apiRoot}/${apiName}/${apiMajorVersion}/alarms
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
GET Alarms Task
Log Query VNF The GET method queries information about multiple alarms.
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Log Execute Query and validate response
Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
GET Alarms Task with filter
Log Query VNF The GET method queries information about multiple alarms with filters.
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Log Execute Query and validate response
Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?${alarm_filter}=${managedObjectId}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
GET Alarms Task with invalid filter
Log Query VNF The GET method queries information about multiple alarms with filters.
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Log Execute Query and validate response
Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?${invalid_alarm_filter}=${managedObjectId}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
GET Alarms Task with all_fields attribute selector
Log Query VNF The GET method queries information about multiple alarms, using fields
Set Headers {"Accept": "${ACCEPT_JSON}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
GET ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?exclude_default
${output}= Output response
Set Suite Variable ${response} ${output}
GET Alarms Task with exclude_default attribute selector
Log Query VNF The GET method queries information about multiple alarms, using fields
Set Headers {"Accept": "${ACCEPT_JSON}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
GET ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?exclude_default
${output}= Output response
Set Suite Variable ${response} ${output}
GET Alarms Task with fields attribute selector
Log Query VNF The GET method queries information about multiple alarms, using fields
Set Headers {"Accept": "${ACCEPT_JSON}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
GET ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?fields=${fields}
${output}= Output response
Set Suite Variable ${response} ${output}
GET Alarms Task with exclude_fields attribute selector
Log Query VNF The GET method queries information about multiple alarms, using fields
Set Headers {"Accept": "${ACCEPT_JSON}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
GET ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?exclude_fields=${fields}
${output}= Output response
Set Suite Variable ${response} ${output}
Check HTTP Response Status Code Is
[Arguments] ${expected_status}
Should Be Equal As Strings ${response['status']} ${expected_status}
Log Status code validated
Check HTTP Response Header Contains
[Arguments] ${CONTENT_TYPE}
Log ${response['headers']}
Should Contain ${response['headers']} ${CONTENT_TYPE}
Log Header is present
Check HTTP Response Body Json Schema Is
[Arguments] ${input}
Run Keyword If '${input}' == 'ProblemDetails' Should Contain ${response['headers']['Content-Type']} application/problem+json
... ELSE Should Contain ${response['headers']['Content-Type']} application/json
${schema} = Catenate SEPARATOR= ${input} .schema.json
Validate Json ${schema} ${response['body']}
Log Json Schema Validation OK
Check HTTP Response Header Contain Link
${linkURL}= Get Value From Json ${response['headers']} $..Link
Should Not Be Empty ${linkURL}
GET Alarms Task with filter "id"
Log Query VNF The GET method queries information about multiple alarms with filters "id".
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Log Execute Query and validate response
Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?id=${alarmId}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "id"
Should Be Equal As Strings ${response['body']['id']} ${alarmId}
GET Alarms Task with filter "vnfcInstanceIds"
Log Query VNF The GET method queries information about multiple alarms with filters "vnfcInstanceIds".
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Log Execute Query and validate response
Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?vnfcInstanceIds=${vnfcInstanceIds}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "vnfcInstanceIds"
:FOR ${item} IN @{response['body']}
Lists Should Be Equal ${item['vnfcInstanceIds']} ${vnfcInstanceIds}
END
GET Alarms Task with filter "rootCauseFaultyResource_faultyResourceType"
Log Query VNF The GET method queries information about multiple alarms with filters "rootCauseFaultyResource.faultyResourceType".
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Log Execute Query and validate response
Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?rootCauseFaultyResource.faultyResourceType=${faultyResourceType}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "rootCauseFaultyResource_faultyResourceType"
:FOR ${item} IN @{response['body']}
Should Be Equal As Strings ${item['rootCauseFaultyResource']['faultyResourceType']} ${faultyResourceType}
END
GET Alarms Task with filter "eventType"
Log Query VNF The GET method queries information about multiple alarms with filters "eventType".
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Log Execute Query and validate response
Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?eventType=${eventType}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "eventType"
:FOR ${item} IN @{response['body']}
Should Be Equal As Strings ${item['eventType']} ${eventType}
END
GET Alarms Task with filter "perceivedSeverity"
Log Query VNF The GET method queries information about multiple alarms with filters "perceivedSeverity".
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Log Execute Query and validate response
Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?perceivedSeverity=${perceivedSeverity}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "perceivedSeverity"
:FOR ${item} IN @{response['body']}
Should Be Equal As Strings ${item['perceivedSeverity']} ${PerceivedSeverity}
END
GET Alarms Task with filter "probableCause"
Log Query VNF The GET method queries information about multiple alarms with filters "probableCause".
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Log Execute Query and validate response
Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?probableCause=${probableCause}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "probableCause"
:FOR ${item} IN @{response['body']}
Should Be Equal As Strings ${item['probableCause']} ${probableCause}
END
\ No newline at end of file
SOL002/VNFFaultManagement-API/ApiVersion.robot 0 → 100644
View file @ 132ae1a2
*** Settings ***
Resource environment/variables.txt
Library REST ${VNFM_SCHEMA}://${VNFM_HOST}:${VNFM_PORT} ssl_verify=false
Library DependencyLibrary
Library JSONLibrary
Library JSONSchemaLibrary schemas/
*** Test Cases ***
POST API Version - Method not implemented
[Documentation] Test ID: 6.3.4.7.1
... Test title: POST API version - Method not implemented
... Test objective: The objective is to test that POST method is not implemented
... Pre-conditions: none
... Reference: Clause 9.3.3.3.1 - ETSI GS NFV-SOL 013 v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
POST API Version
Check HTTP Response Status Code Is 405
GET API Version
[Documentation] Test ID: 6.3.4.7.2
... Test title: GET API Version
... Test objective: The objective is to test that GET method successfully return ApiVersionInformation
... Pre-conditions: none
... Reference: Clause 9.3.3.3.2 - ETSI GS NFV-SOL 013 v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
GET API Version
Check HTTP Response Status Code Is 200
Check HTTP Response Body Json Schema Is ApiVersionInformation
PUT API Version - Method not implemented
[Documentation] Test ID: 6.3.4.7.3
... Test title: PUT API Version - Method not implemented
... Test objective: The objective is to test that PUT method is not implemented
... Pre-conditions: none
... Reference: Clause 9.3.3.3.3 - ETSI GS NFV-SOL 013 v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
PUT API Version
Check HTTP Response Status Code Is 405
PATCH API Version - Method not implemented
[Documentation] Test ID: 6.3.4.7.4
... Test title: PATCH API Version - Method not implemented
... Test objective: The objective is to test that PATCH method is not implemented
... Pre-conditions: none
... Reference: Clause 9.3.3.3.4 - ETSI GS NFV-SOL 013 v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
PATCH API Version
Check HTTP Response Status Code Is 405
DELETE API Version - Method not implemented
[Documentation] Test ID: 6.3.4.7.5
... Test title: DELETE API Version - Method not implemented
... Test objective: The objective is to test that DELETE method is not implemented
... Pre-conditions: none
... Reference: Clause 9.3.3.3.5 - ETSI GS NFV-SOL 013 v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
DELETE API Version
Check HTTP Response Status Code Is 405
POST API Version with apiMajorVerion - Method not implemented
[Documentation] Test ID: 6.3.4.7.6
... Test title: POST API version with apiMajorVerion - Method not implemented
... Test objective: The objective is to test that POST method is not implemented
... Pre-conditions: none
... Reference: Clause 9.3.3.3.1 - ETSI GS NFV-SOL 013 v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
POST API Version
Check HTTP Response Status Code Is 405
GET API Version with apiMajorVerion
[Documentation] Test ID: 6.3.4.7.7
... Test title: GET API Version with apiMajorVerion
... Test objective: The objective is to test that GET method successfully return ApiVersionInformation
... Pre-conditions: none
... Reference: Clause 9.3.3.3.2 - ETSI GS NFV-SOL 013 v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
GET API Version
Check HTTP Response Status Code Is 200
Check HTTP Response Body Json Schema Is ApiVersionInformation
PUT API Version with apiMajorVerion - Method not implemented
[Documentation] Test ID: 6.3.4.7.8
... Test title: PUT API Version with apiMajorVerion - Method not implemented
... Test objective: The objective is to test that PUT method is not implemented
... Pre-conditions: none
... Reference: Clause 9.3.3.3.3 - ETSI GS NFV-SOL 013 v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
PUT API Version
Check HTTP Response Status Code Is 405
PATCH API Version with apiMajorVerion - Method not implemented
[Documentation] Test ID: 6.3.4.7.9
... Test title: PATCH API Version with apiMajorVerion - Method not implemented
... Test objective: The objective is to test that PATCH method is not implemented
... Pre-conditions: none
... Reference: Clause 9.3.3.3.4 - ETSI GS NFV-SOL 013 v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
PATCH API Version
Check HTTP Response Status Code Is 405
DELETE API Version with apiMajorVerion - Method not implemented
[Documentation] Test ID: 6.3.4.7.10
... Test title: DELETE API Version with apiMajorVerion - Method not implemented
... Test objective: The objective is to test that DELETE method is not implemented
... Pre-conditions: none
... Reference: Clause 9.3.3.3.5 - ETSI GS NFV-SOL 013 v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
DELETE API Version
Check HTTP Response Status Code Is 405
*** Keywords ***
POST API Version
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Post ${apiRoot}/${apiName}/api_versions
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
GET API Version
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Get ${apiRoot}/${apiName}/api_versions
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
PUT API Version
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Put ${apiRoot}/${apiName}/api_versions
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
PATCH API Version
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Patch ${apiRoot}/${apiName}/api_versions
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
DELETE API Version
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Delete ${apiRoot}/${apiName}/api_versions
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
POST API Version with apiMajorVersion
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Post ${apiRoot}/${apiName}/${apiMajorVersion}/api_versions
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
GET API Version with apiMajorVersion
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Get ${apiRoot}/${apiName}/${apiMajorVersion}/api_versions
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
PUT API Version with apiMajorVersion
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Put ${apiRoot}/${apiName}/${apiMajorVersion}/api_versions
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
PATCH API Version with apiMajorVersion
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Patch ${apiRoot}/${apiName}/${apiMajorVersion}/api_versions
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
DELETE API Version with apiMajorVersion
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Delete ${apiRoot}/${apiName}/${apiMajorVersion}/api_versions
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
Check HTTP Response Status Code Is
[Arguments] ${expected_status}
Should Be Equal As Strings ${response['status']} ${expected_status}
Log Status code validated
Check HTTP Response Body Json Schema Is
[Arguments] ${input}
${schema} = Catenate SEPARATOR= ${input} .schema.json
Validate Json ${schema} ${response['body']}
Log Json Schema Validation OK
\ No newline at end of file
SOL002/VNFFaultManagement-API/EscalatePerceivedSeverityTask.robot
View file @ 132ae1a2
*** Settings ***
Resource environment/variables.txt
Library REST ${VNFM_SCHEMA}://${VNFM_HOST}:${VNFM_PORT}
... spec=SOL002-VNFFaultManagement-API.yaml
Suite setup Check resource existance
Library REST ${VNFM_SCHEMA}://${VNFM_HOST}:${VNFM_PORT} ssl_verify=false
Library JSONSchemaLibrary
Suite Setup Check resource existence
*** Test Cases ***
Escalate the perceived severity
[Documentation] escalate the perceived severity of an alarm with the VNFM
Log escalate the perceived severity of an alarm with the VNFM
Set Headers {"Accept":"${ACCEPT}"}
Set Headers {"Content-Type": "${CONTENT_TYPE}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Post ${apiRoot}/${apiName}/${apiVersion}/alarms/${alarmId}/escalate ${PerceivedSeverity}
Integer response status 204
Log Status code validated
[Documentation] Test ID: 6.3.4.3.1
... Test title: Escalate the perceived severity
... Test objective: To enable the consumer to escalate the perceived severity of an alarm that is represented by an individual alarm resource.
... Pre-conditions: The resource representing the individual alarm has been created
... Reference: Clause 7.4.4.3.1 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
Post escalate severity
Check HTTP Response Status Code Is 204
GET Escalate the perceived severity - Method not implemented
log Trying to perform a GET. This method should not be implemented
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Get ${apiRoot}/${apiName}/${apiVersion}/alarms/${alarmId}/escalate
Log Validate Status code
Integer response status 405
[Documentation] Test ID: 6.3.4.3.2
... Test title: GET Escalate the perceived severity - Method not implemented
... Test objective: The objective is to test that the GET HTTP method not implemented for escalate perceived severity
... Pre-conditions: none
... Reference: Clause 7.4.4.3.2 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
Get escalate severity
Check HTTP Response Status Code Is 405
PUT Escalate the perceived severity - Method not implemented
log Trying to perform a PUT. This method should not be implemented
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Put ${apiRoot}/${apiName}/${apiVersion}/alarms/${alarmId}/escalate
Log Validate Status code
Integer response status 405
[Documentation] Test ID: 6.3.4.3.3
... Test title: PUT Escalate the perceived severity - Method not implemented
... Test objective: The objective is to test that the PUT HTTP method not implemented for escalate perceived severity
... Pre-conditions: none
... Reference: Clause 7.4.4.3.3 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
Put escalate severity
Check HTTP Response Status Code Is 405
PATCH Escalate the perceived severity - Method not implemented
log Trying to perform a PATCH. This method should not be implemented
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Patch ${apiRoot}/${apiName}/${apiVersion}/alarms/${alarmId}/escalate
Log Validate Status code
Integer response status 405
[Documentation] Test ID: 6.3.4.3.4
... Test title: PATCH Escalate the perceived severity - Method not implemented
... Test objective: The objective is to test that the PATCH HTTP method not implemented for escalate perceived severity
... Pre-conditions: none
... Reference: Clause 7.4.4.3.4 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
PATCH escalate severity
Check HTTP Response Status Code Is 405
DELETE Escalate the perceived severity - Method not implemented
log Trying to perform a DELETE. This method should not be implemented
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Delete ${apiRoot}/${apiName}/${apiVersion}/alarms/${alarmId}/escalate
Log Validate Status code
Integer response status 405
[Documentation] Test ID: 6.3.4.3.5
... Test title: DELETE Escalate the perceived severity - Method not implemented
... Test objective: The objective is to test that the DELETE HTTP method not implemented for escalate perceived severity
... Pre-conditions: none
... Reference: Clause 7.4.4.3.5 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
Delete escalate severity
Check HTTP Response Status Code Is 405
*** Key words ***
Check resource existance
*** Keywords ***
Check resource existence
Set Headers {"Accept":"${ACCEPT}"}
Set Headers {"Content-Type": "${CONTENT_TYPE}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Get ${apiRoot}/${apiName}/${apiVersion}/alarms/${alarmId}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms/${alarmId}
Integer response status 200
POST escalate severity
Log escalate the perceived severity of an alarm with the VNFM
Set Headers {"Accept":"${ACCEPT}"}
Set Headers {"Content-Type": "${CONTENT_TYPE}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Post ${apiRoot}/${apiName}/${apiMajorVersion}/alarms/${alarmId}/escalate ${PerceivedSeverity}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
GET escalate severity
log Trying to perform a GET. This method should not be implemented
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms/${alarmId}/escalate
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
PUT escalate severity
log Trying to perform a PUT. This method should not be implemented
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Put ${apiRoot}/${apiName}/${apiMajorVersion}/alarms/${alarmId}/escalate
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
PATCH escalate severity
log Trying to perform a PATCH. This method should not be implemented
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Patch ${apiRoot}/${apiName}/${apiMajorVersion}/alarms/${alarmId}/escalate
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
DELETE escalate severity
log Trying to perform a DELETE. This method should not be implemented
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Delete ${apiRoot}/${apiName}/${apiMajorVersion}/alarms/${alarmId}/escalate
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
Check HTTP Response Status Code Is
[Arguments] ${expected_status}
Should Be Equal As Strings ${response['status']} ${expected_status}
Log Status code validated
Check HTTP Response Body Json Schema Is
[Arguments] ${input}
Run Keyword If '${input}' == 'ProblemDetails' Should Contain ${response['headers']['Content-Type']} application/problem+json
... ELSE Should Contain ${response['headers']['Content-Type']} application/json
${schema} = Catenate SEPARATOR= ${input} .schema.json
Validate Json ${schema} ${response['body']}
Log Json Schema Validation OK
\ No newline at end of file
SOL002/VNFFaultManagement-API/IndividualAlarm.robot
View file @ 132ae1a2
*** Settings ***
# Suite setup Expect spec SOL003-VNFLifecycleManagement-API.yaml
Resource environment/variables.txt
Library REST ${VNFM_SCHEMA}://${VNFM_HOST}:${VNFM_PORT}
... spec=SOL002-VNFFaultManagement-API.yaml
Library REST ${VNFM_SCHEMA}://${VNFM_HOST}:${VNFM_PORT} ssl_verify=false
Library OperatingSystem
Library JSONLibrary
Library JSONSchemaLibrary schemas/
Library DependencyLibrary
*** Variables ***
${Etag}= an etag
${Etag_modified}= a modified etag
*** Variables **
${original_etag} 1234
*** Test cases ***
*** Test Cases ***
POST Alarm - Method not implemented
log Trying to perform a POST. This method should not be implemented
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Post ${apiRoot}/${apiName}/${apiVersion}/alarms/${alarmId}
Log Validate Status code
Integer response status 405
[Documentation] Test ID: 6.3.4.2.1
... Test title: POST Alarm - Method not implemented
... Test objective: The objective is to test that the method is not implemented
... Pre-conditions: none
... Reference: Clause 7.4.3.3.1 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
POST Alarm Task
Check HTTP Response Status Code Is 405
Get information about a configuration
Log Query VNF The GET method queries information about an alarm.
Set Headers {"Accept":"${ACCEPT}"}
Set Headers {"Content-Type": "${CONTENT_TYPE}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Log Execute Query and validate response
Get ${apiRoot}/${apiName}/${apiVersion}/alarms/${alarmId}
${Etag}= Output response headers Etag
Log Validate Status code
Integer response status 200
${contentType}= Output response headers Content-Type
Should Contain ${contentType} ${CONTENT_TYPE}
${result}= Output response body
${json}= evaluate json.loads('''${result}''') json
Validate Json alarm.schema.json ${json}
Log Validation OK
GET information about an individual alarm
[Documentation] Test ID: 6.3.4.2.2
... Test title: GET information about an individual alarm
... Test objective: The objective is to read an individual alarm.
... Pre-conditions: The related alarm exists
... Reference: Clause 7.4.3.3.2 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
GET Alarm Task
Check HTTP Response Status Code Is 200
Check HTTP Response Body Json Schema Is alarm
PUT Individual Alarm - Method not implemented
[Documentation] Test ID: 6.3.4.2.3
... Test title: PUT Individual Alarm - Method not implemented
... Test objective: The objective is to test that the method is not implemented
... Pre-conditions: none
... Reference: Clause 7.4.3.3.3 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
PUT Alarm Task
Check HTTP Response Status Code Is 405
PATCH Individual Alarm
[Documentation] Test ID: 6.3.4.2.4
... Test title: PATCH Individual Alarm
... Test objective: The objective is to Modify an individual alarm resource
... Pre-conditions: The related alarm exists
... Reference: Clause 7.4.3.3.4 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
PATCH Alarm Task
Check HTTP Response Status Code Is 200
Check HTTP Response Body Json Schema Is alarmModifications
PATCH Individual Alarm - Precondition failed
[Documentation] Test ID: 6.3.4.2.5
... Test title: PATCH Individual Alarm - Precondition failed
... Test objective: The objective is to attempt to Modify an individual alarm resource, where the precondition was not met
... Pre-conditions: The related alarm exists
... Reference: Clause 7.4.3.3.4 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: The alarm resource is not modified
PATCH Alarm Task with wrong precondition
Check HTTP Response Status Code Is 412
Check HTTP Response Body Json Schema Is ProblemDetails
Check Postcondition VNF individual alarm Unmodified (Implicit)
PATCH Individual Alarm - Conflict
[Documentation] Test ID: 6.3.4.2.6
... Test title: PATCH Individual Alarm - Conflict
... Test objective: The objective is to Modify an individual alarm resource
... Pre-conditions: The related alarm exists
... Reference: Clause 7.4.3.3.4 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: The alarm resource is not modified
PATCH Alarm Task
Check HTTP Response Status Code Is 409
Check HTTP Response Body Json Schema Is ProblemDetails
Check Postcondition VNF individual alarm Unmodified (Implicit)
DELETE Individual Alarm - Method not implemented
[Documentation] Test ID: 6.3.4.2.7
... Test title: DELETE Individual Alarm - Method not implemented
... Test objective: The objective is to test that the method is not implemented
... Pre-conditions: none
... Reference: Clause 7.4.3.3.5 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
DELETE Alarm Task
Check HTTP Response Status Code Is 405
GET information about an individual alarm - Not Found
[Documentation] Test ID: 6.3.4.2.8
... Test title: GET information about an individual alarm - Not Found
... Test objective: The objective is to test that GET method fail retrieving status information about individaual Alarms when alarm is not present.
... Pre-conditions: The related alarm doesnot exists
... Reference: Clause 7.4.3.3.2 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
GET Alarm Task
Check HTTP Response Status Code Is 404
Check HTTP Response Body Json Schema Is ProblemDetails
PUT Alarm - Method not implemented
*** Keywords ***
POST Alarm Task
log Trying to perform a POST. This method should not be implemented
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Post ${apiRoot}/${apiName}/${apiMajorVersion}/alarms/${alarmId}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
PUT Alarm Task
log Trying to perform a PUT. This method should not be implemented
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Put ${apiRoot}/${apiName}/${apiVersion}/alarms/${alarmId}
Log Validate Status code
Integer response status 405
PATCH Alarm
[Documentation] This method modifies an individual alarm resource
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
${body}= Get File jsons/alarmModifications.json
Put ${apiRoot}/${apiName}/${apiMajorVersion}/alarms/${alarmId} ${body}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
PATCH Alarm Task
log Trying to perform a PATCH. This method modifies an individual alarm resource
Set Headers {"Accept":"${ACCEPT}"}
Set Headers {"Content-Type": "${CONTENT_TYPE_PATCH}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
${body}= Get File json/alarmModifications.json
Patch ${apiRoot}/${apiName}/${apiVersion}/alarms/${alarmId} ${body}
Log Validate Status code
${Etag_modified}= Output response headers Etag
Integer response status 200
${contentType}= Output response headers Content-Type
Should Contain ${contentType} ${CONTENT_TYPE}
${result}= Output response body
${json}= evaluate json.loads('''${result}''') json
Validate Json alarmModifications.schema.json ${json}
Log Validation OK
PATCH Alarm - Conflict
[Documentation] Conflict
... The operation cannot be executed currently, due to a conflict with the state of the “Individual alarm” resource.
... Typically, this is due to the fact that the alarm is already in the state that is requested to be set (such as trying to acknowledge an already-acknowledged alarm).
... The response body shall contain a ProblemDetails structure, in which the “detail” attribute should convey more information about the error.
Depends On Test PATCH Alarm # If the previous test scceeded, it means that the alarm is in ackownledged state
Set Headers {"Content-Type": "${CONTENT_TYPE_PATCH}"}
Set Headers {"If-Match": "${original_etag[0]}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
${body}= Get File jsons/alarmModifications.json
Patch ${apiRoot}/${apiName}/${apiMajorVersion}/alarms/${alarmId} ${body}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
PATCH Alarm Task with wrong precondition
log Trying to perform a PATCH. This method modifies an individual alarm resource
Set Headers {"Accept":"${ACCEPT}"}
Set Headers {"Content-Type": "${CONTENT_TYPE_PATCH}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
${body}= Get File json/alarmModifications.json
Patch ${apiRoot}/${apiName}/${apiVersion}/alarms/${alarmId} ${body}
Log Validate Status code
Integer response status 409
${problemDetails}= Output response body
${json}= evaluate json.loads('''${problemDetails}''') json
Validate Json ProblemDetails.schema.json ${json}
Log Validation OK
PATCH Alarm - Precondition failed
[Documentation] Precondition Failed
... A precondition given in an HTTP request header is not fulfilled. Typically, this is due to an ETag mismatch,
... indicating that the resource was modified by another entity. The response body should contain a ProblemDetails structure,
... in which the “detail” attribute should convey more information about the error.
Depends On Test PATCH Alarm # If the previous test scceeded, it means that Etag has been modified
log Trying to perform a PATCH. This method modifies an individual alarm resource
Set Headers {"Accept":"${ACCEPT}"}
Set Headers {"Content-Type": "${CONTENT_TYPE_PATCH}"}
Set Headers {"If-Match": "${Etag}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
${body}= Get File json/alarmModifications.json
Patch ${apiRoot}/${apiName}/${apiVersion}/alarms/${alarmId} ${body}
Log Validate Status code
Integer response status 412
${problemDetails}= Output response body
${json}= evaluate json.loads('''${problemDetails}''') json
Validate Json ProblemDetails.schema.json ${json}
Log Validation OK
DELETE Alarm - Method not implemented
Set Headers {"Content-Type": "${CONTENT_TYPE_PATCH}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
${body}= Get File jsons/alarmModifications.json
GET ${apiRoot}/${apiName}/${apiMajorVersion}/alarms/${alarmId}
${origOutput}= Output response
Set Suite Variable ${origResponse} ${origOutput}
Set Headers {"If-Match": "${wrong_etag}"}
Patch ${apiRoot}/${apiName}/${apiMajorVersion}/alarms/${alarmId} ${body}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
DELETE Alarm Task
log Trying to perform a DELETE. This method should not be implemented
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Delete ${apiRoot}/${apiName}/${apiVersion}/alarms/${alarmId}
Log Validate Status code
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Delete ${apiRoot}/${apiName}/${apiMajorVersion}/alarms/${alarmId}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
GET Alarm Task
Log Query VNF The GET method queries information about individual alarm.
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Log Execute Query and validate response
Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms/${alarmId}
${etag} Output response headers ETag
Set Suite Variable &{original_etag} ${etag}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
GET Alarm Task with filter
Log Query VNF The GET method queries information about individual alarm with filters.
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Log Execute Query and validate response
Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?${alarm_filter}=${managedObjectId}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
GET Alarm Task with invalid filter
Log Query VNF The GET method queries information about individual alarm with filters.
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Log Execute Query and validate response
Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?${invalid_alarm_filter}=${managedObjectId}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
Check HTTP Response Status Code Is
[Arguments] ${expected_status}
Should Be Equal As Strings ${response['status']} ${expected_status}
Log Status code validated
Check HTTP Response Body Json Schema Is
[Arguments] ${input}
Run Keyword If '${input}' == 'ProblemDetails' Should Contain ${response['headers']['Content-Type']} application/problem+json
... ELSE Should Contain ${response['headers']['Content-Type']} application/json
${schema} = Catenate SEPARATOR= ${input} .schema.json
Validate Json ${schema} ${response['body']}
Log Json Schema Validation OK
Check Postcondition VNF individual alarm Unmodified (Implicit)
Log Check Postcondition subscription is not modified
GET Alarm Task
Should Be Equal As Strings ${origResponse['body']['callbackUri']} ${response['body']['callbackUri']}
Integer response status 405
SOL002/VNFFaultManagement-API/IndividualSubscription.robot
View file @ 132ae1a2
......@@ -2,68 +2,158 @@
Resource environment/variables.txt
Library JSONLibrary
Library JSONSchemaLibrary schemas/
Library REST ${VNFM_SCHEMA}://${VNFM_HOST}:${VNFM_PORT}
... spec=SOL002-VNFFaultManagement-API.yaml
Library REST ${VNFM_SCHEMA}://${VNFM_HOST}:${VNFM_PORT} ssl_verify=false
Documentation This resource represents an individual subscription for VNF alarms.
... The client can use this resource to read and to terminate a subscription to notifications related to VNF fault management.
Suite setup Check resource existance
Suite Setup Check resource existence
*** Test Cases ***
Post Individual Subscription - Method not implemented
POST Individual Subscription - Method not implemented
[Documentation] Test ID: 6.3.4.5.1
... Test title: POST Individual Subscription - Method not implemented
... Test objective: The objective is to test that the method is not implemented
... Pre-conditions: none
... Reference: Clause 7.4.6.3.1 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
Post Create individual subscription
Check HTTP Response Status Code Is 405
GET Information about an individual subscription
[Documentation] Test ID: 6.3.4.5.2
... Test title: GET Information about an individual subscription
... Test objective: The objective is to read an individual subscription for VNF alarms subscribed by the client
... Pre-conditions: The subscription with the given id exists
... Reference: Clause 7.4.6.3.2 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
Get individual subscription
Check HTTP Response Status Code Is 200
Check HTTP Response Body Json Schema Is FmSubscription
PUT an individual subscription - Method not implemented
[Documentation] Test ID: 6.3.4.5.3
... Test title: PUT an individual subscription - Method not implemented
... Test objective: The objective is to test that the method is not implemented
... Pre-conditions: none
... Reference: Clause 7.4.6.3.3 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
Put individual subscription
Check HTTP Response Status Code Is 405
PATCH an individual subscription - Method not implemented
[Documentation] Test ID: 6.3.4.5.4
... Test title: PATCH an individual subscription - Method not implemented
... Test objective: The objective is to test that the method is not implemented
... Pre-conditions: none
... Reference: Clause 7.4.6.3.4 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
Patch individual subscription
Check HTTP Response Status Code Is 405
DELETE an individual subscription
[Documentation] Test ID: 6.3.4.5.5
... Test title: DELETE an individual subscription
... Test objective: The objective is to test that the deletion of a individual subscription resource.
... Pre-conditions: one or more subscription already exsist
... Reference: Clause 7.4.6.3.5 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: the subscription is deleted
Delete individual subscription
Check HTTP Response Status Code Is 204
Check Postcondition resource is deleted
GET Information about an individual subscription - Not Found
[Documentation] Test ID: 6.3.4.5.6
... Test title: GET Information about an individual subscription - Not Found
... Test objective: The objective is to test that GET method fail retrieving individual subscription for VNF alarms subscribed by the client because it is not present.
... Pre-conditions: The subscription with the given id donot exists
... Reference: Clause 7.4.6.3.2 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
Get individual subscription
Check HTTP Response Status Code Is 404
Check HTTP Response Body Json Schema Is ProblemDetails
*** Keywords ***
Check resource existence
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Get ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions/${subscriptionId}
Integer response status 200
Post Create individual subscription
log Trying to perform a POST. This method should not be implemented
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Post ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${subscriptionId}
Log Validate Status code
Output response
Integer response status 405
Get Information about an individual subscription
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Post ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions/${subscriptionId}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
Get individual subscription
log Trying to get information about an individual subscription
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Get ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${subscriptionId}
Log Validate Status code
Integer response status 200
${contentType}= Output response headers Content-Type
Should Contain ${contentType} ${CONTENT_TYPE}
${result}= Output response body
${json}= evaluate json.loads('''${result}''') json
Validate Json subscriptions.schema.json ${json}
Log Validation OK
PUT an individual subscription - Method not implemented
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Get ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions/${subscriptionId}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
Get individual subscription - filter
Log Get the list of active individual subscription using a filter
Set Headers {"Accept": "${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
GET ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions?${sub_filter}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
Get individual subscription - invalid filter
Log Get the list of active individual subscription using an invalid filter
Set Headers {"Accept": "${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
GET ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions?${sub_filter_invalid}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
PUT individual subscription
log Trying to perform a PUT. This method should not be implemented
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Put ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${subscriptionId}
Log Validate Status code
Output response
Integer response status 405
PATCH an individual subscription - Method not implemented
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Put ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions/${subscriptionId}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
PATCH individual subscription
log Trying to perform a PATCH. This method should not be implemented
Set Headers {"Accept":"${ACCEPT}"}
Set Headers {"Content-Type": "${CONTENT_TYPE}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Patch ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${subscriptionId}
Log Validate Status code
Output response
Integer response status 405
DELETE an individual subscription
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Patch ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions/${subscriptionId}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
DELETE individual subscription
log Try to delete an individual subscription
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Delete ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${subscriptionId}
Log Validate Status code
Output response
Integer response status 204
*** Key words ***
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Delete ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions/${subscriptionId}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
Check HTTP Response Status Code Is
[Arguments] ${expected_status}
Should Be Equal As Strings ${response['status']} ${expected_status}
Log Status code validated
Check HTTP Response Body Json Schema Is
[Arguments] ${input}
Run Keyword If '${input}' == 'ProblemDetails' Should Contain ${response['headers']['Content-Type']} application/problem+json
... ELSE Should Contain ${response['headers']['Content-Type']} application/json
${schema} = Catenate SEPARATOR= ${input} .schema.json
Validate Json ${schema} ${response['body']}
Log Json Schema Validation OK
Check resource existance
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Get ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${subscriptionId}
Integer response status 200
\ No newline at end of file
Check Postcondition resource is deleted
Get individual subscription
Check HTTP Response Status Code Is 404
\ No newline at end of file
SOL002/VNFFaultManagement-API/NotificationEndpoint.robot
View file @ 132ae1a2
*** Settings ***
Resource environment/variables.txt
Suite Setup Create Sessions
Suite Teardown Terminate All Processes kill=true
Library MockServerLibrary
Library Process
Library String
Library OperatingSystem
Library REST ${CONSUMER_SCHEMA}://${CONSUMER_HOST}:${notification_port}
*** Variables ***
${sleep_interval} 20s
Resource environment/variables.txt
Library JSONLibrary
Library JSONSchemaLibrary schemas/
Library REST ${VNFM_SCHEMA}://${VNFM_HOST}:${VNFM_PORT} ssl_verify=false
Suite Setup Check resource existence and get CallbackUri
*** Test Cases ***
Deliver a notification - Alarm
log The POST method delivers a notification - Information of a VNF alarm.
${json}= Get File schemas/alarmNotification.schema.json
${BODY}= evaluate json.loads('''${json}''') json
Log Creating mock request and response to handle alarmNotification
&{req}= Create Mock Request Matcher POST ${notification_ep} body_type="JSON_SCHEMA" body=${BODY}
&{rsp}= Create Mock Response headers="Content-Type: application/json" status_code=204
Create Mock Expectation ${req} ${rsp}
Sleep ${sleep_interval}
Log Verifying results
Verify Mock Expectation ${req}
Log Cleaning the endpoint
Clear Requests ${notification_ep}
Deliver a notification - Alarm Clearance
log The POST method delivers a notification - Information of a VNF alarm.
${json}= Get File schemas/alarmClearedNotification.schema.json
${BODY}= evaluate json.loads('''${json}''') json
Log Creating mock request and response to handle alarmNotification
&{req}= Create Mock Request Matcher POST ${notification_ep} body_type="JSON_SCHEMA" body=${BODY}
&{rsp}= Create Mock Response headers="Content-Type: application/json" status_code=204
Create Mock Expectation ${req} ${rsp}
Sleep ${sleep_interval}
Log Verifying results
Verify Mock Expectation ${req}
Log Cleaning the endpoint
Clear Requests ${notification_ep}
Deliver a notification - Alarm List Rebuilt
log The POST method delivers a notification - Information of a VNF alarm.
${json}= Get File schemas/alarmListRebuiltNotification.schema.json
${BODY}= evaluate json.loads('''${json}''') json
Log Creating mock request and response to handle alarmNotification
&{req}= Create Mock Request Matcher POST ${notification_ep} body_type="JSON_SCHEMA" body=${BODY}
&{rsp}= Create Mock Response headers="Content-Type: application/json" status_code=204
Create Mock Expectation ${req} ${rsp}
Sleep ${sleep_interval}
Log Verifying results
Verify Mock Expectation ${req}
Log Cleaning the endpoint
Clear Requests ${notification_ep}
Test a notification end point
log The GET method allows the server to test the notification endpoint
&{req}= Create Mock Request Matcher GET ${notification_ep}
&{rsp}= Create Mock Response headers="Content-Type: application/json" status_code=204
Create Mock Expectation ${req} ${rsp}
Sleep ${sleep_interval}
Verify Mock Expectation ${req}
Clear Requests ${notification_ep}
VNF Fault Alarm Notification
[Documentation] Test ID: 6.3.4.8.1
... Test title: VNF Fault Alarm Notification
... Test objective: The objective is to test that VNF Fault Alarm Notification is delivered with success to the notification consumer
... Pre-conditions: A VNF instance is instantiated, and a subscription for fault alarm notifications is available in the VNFM.
... Reference: Clause 7.4.7.3.1 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_Notif_Endpoint
... Applicability: none
... Post-Conditions: none
Post Alarm Notification
Check HTTP Response Status Code Is 204
VNF Fault Alarm Cleared Notification
[Documentation] Test ID: 6.3.4.8.2
... Test title: VNF Fault Alarm Cleared Notification
... Test objective: The objective is to test that VNF Fault Alarm Cleared Notification is delivered with success to the notification consumer
... Pre-conditions: A VNF instance is instantiated, and a subscription for fault alarm cleared notifications is available in the VNFM.
... Reference: Clause 7.4.7.3.1 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_Notif_Endpoint
... Applicability: none
... Post-Conditions: none
Post Alarm Cleared Notification
Check HTTP Response Status Code Is 204
VNF Fault Alarm List Rebuilt Notification
[Documentation] Test ID: 6.3.4.8.3
... Test title: VNF Fault List Rebuilt Alarm List Rebuilt Notification
... Test objective: The objective is to test that VNF Fault Alarm List Rebuilt Notification is delivered with success to the notification consumer
... Pre-conditions: A VNF instance is instantiated, and a subscription for fault alarm list rebuilt notifications is available in the VNFM.
... Reference: Clause 7.4.7.3.1 - ETSI GS NFV-SOL 002 [2] v2.8.1
... Config ID: Config_prod_Notif_Endpoint
... Applicability: none
... Post-Conditions: none
Post Alarm List Rebuilt Notification
Check HTTP Response Status Code Is 204
PUT notification - Method not implemented
log Trying to perform a PUT. This method should not be implemented
Put ${notification_ep}
Log Validate Status code
Output response
Integer response status 405
*** Keywords ***
Check resource existence and get CallbackUri
Set Headers {"Accept":"${ACCEPT}"}
Set Headers {"Content-Type": "${CONTENT_TYPE}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Get ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions/${subscriptionId}
Integer response status 200
Validate Json response body FmSubscription.schema.json
Set Global Variable ${callbackResp} response body callbackUri
Check HTTP Response Status Code Is
[Arguments] ${expected_status}
Should Be Equal As Strings ${response['status']} ${expected_status}
Log Status code validated
PATCH subscriptions - Method not implemented
log Trying to perform a PATCH. This method should not be implemented
Patch ${notification_ep}
Log Validate Status code
Output response
Integer response status 405
Post Alarm Notification
log Trying to perform a POST to get notification
Set Headers {"Accept":"${ACCEPT}"}
Set Headers {"Content-Type": "${CONTENT_TYPE}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
${template} = Get File jsons/AlarmNotification.json
${body}= Format String ${template} subscriptionId=${subscriptionId}
Post ${callbackResp} ${body}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
DELETE subscriptions - Method not implemented
log Trying to perform a DELETE. This method should not be implemented
Delete ${notification_ep}
Log Validate Status code
Output response
Integer response status 405
*** Keywords ***
Create Sessions
Start Process java -jar ../../bin/mockserver-netty-5.3.0-jar-with-dependencies.jar -serverPort ${notification_port} alias=mockInstance
Wait For Process handle=mockInstance timeout=5s on_timeout=continue
Create Mock Session ${CONSUMER_SCHEMA}://${CONSUMER_HOST}:${notification_port} #The API producer is set to NFVO according to SOL003-7.3.4
\ No newline at end of file
Post Alarm Cleared Notification
log Trying to perform a POST to get notification
Set Headers {"Accept":"${ACCEPT}"}
Set Headers {"Content-Type": "${CONTENT_TYPE}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
${template} = Get File jsons/AlarmClearedNotification.json
${body}= Format String ${template} subscriptionId=${subscriptionId} alarmId=${alarmId}
Post ${callbackResp} ${body}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
Post Alarm List Rebuilt Notification
log Trying to perform a POST to get notification
Set Headers {"Accept":"${ACCEPT}"}
Set Headers {"Content-Type": "${CONTENT_TYPE}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
${template} = Get File jsons/AlarmListRebuiltNotification.json
${body}= Format String ${template} subscriptionId=${subscriptionId}
Post ${callbackResp} ${body}
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
\ No newline at end of file