From b83b29c1ddb7d644d057cf9bd999d0fb33d58988 Mon Sep 17 00:00:00 2001
From: Elian Kraja <e.kraja@nextworks.it>
Date: Fri, 19 Apr 2019 19:01:51 +0200
Subject: [PATCH] updates on SOL003 and SOL005 high level code
---
.../VnfIndicatorNotification.robot | 0
.../environment/variables.txt | 3 +-
...dicatorValueChangeNotification.schema.json | 0
.../environment/variables.txt | 8 -
.../schemas/ProblemDetails.schema.json | 1 -
.../PackageManagementNotification.robot | 0
.../VNFPackageManagementKeywords.robot | 1 -
.../environment/variables.txt | 4 +-
.../PackageChangeNotification.schema.json | 0
.../PackageOnboardingNotification.schema.json | 0
.../environment/variables.txt | 8 -
.../schemas/ProblemDetails.schema.json | 1 -
.../PerformanceManagementNotification.robot | 28 +-
.../VNFPerformanceManagementKeywords.robot | 2 +
.../environment/variables.txt | 3 +
...manceInformationAvailableNotification.json | 24 +-
.../jsons/ThresholdCrossedNotification.json | 0
...formationAvailableNotification.schema.json | 208 +-
.../ThresholdCrossedNotification.schema.json | 224 +-
.../PerformanceManagementNotification.robot | 107 -
.../SOL003-VNFPerformanceManagement-API.json | 5545 -----------------
.../environment/variables.txt | 8 -
.../schemas/ProblemDetails.schema.json | 1 -
.../NSDManagementKeywords.robot | 184 +
.../NSDManagementNotification.robot | 24 +-
SOL005/NSDManagement-API/Subscriptions.robot | 180 +-
.../environment/subscriptions.txt | 3 +-
.../environment/variables.txt | 14 +-
.../jsons/subscriptions.json | 2 +-
.../NSPerformanceManagementKeywords.robot | 210 +
.../Subscriptions.robot | 228 +-
.../environment/variables.txt | 18 +-
.../jsons/CreatePmJobRequest.json | 7 +-
.../jsons/subscriptions.json | 2 +-
34 files changed, 805 insertions(+), 6243 deletions(-)
rename SOL003/{VNFIndicatorNotification-API => VNFIndicator-API}/VnfIndicatorNotification.robot (100%)
rename SOL003/{VNFIndicatorNotification-API => VNFIndicator-API}/schemas/VnfIndicatorValueChangeNotification.schema.json (100%)
delete mode 100644 SOL003/VNFIndicatorNotification-API/environment/variables.txt
delete mode 100644 SOL003/VNFIndicatorNotification-API/schemas/ProblemDetails.schema.json
rename SOL003/{VNFPackageManagementNotification-API => VNFPackageManagement-API}/PackageManagementNotification.robot (100%)
rename SOL003/{VNFPackageManagementNotification-API => VNFPackageManagement-API}/schemas/PackageChangeNotification.schema.json (100%)
rename SOL003/{VNFPackageManagementNotification-API => VNFPackageManagement-API}/schemas/PackageOnboardingNotification.schema.json (100%)
delete mode 100644 SOL003/VNFPackageManagementNotification-API/environment/variables.txt
delete mode 100644 SOL003/VNFPackageManagementNotification-API/schemas/ProblemDetails.schema.json
rename SOL003/{VNFPerformanceManagementNotification-API => VNFPerformanceManagement-API}/jsons/PerformanceInformationAvailableNotification.json (96%)
rename SOL003/{VNFPerformanceManagementNotification-API => VNFPerformanceManagement-API}/jsons/ThresholdCrossedNotification.json (100%)
rename SOL003/{VNFPerformanceManagementNotification-API => VNFPerformanceManagement-API}/schemas/PerformanceInformationAvailableNotification.schema.json (97%)
rename SOL003/{VNFPerformanceManagementNotification-API => VNFPerformanceManagement-API}/schemas/ThresholdCrossedNotification.schema.json (97%)
delete mode 100644 SOL003/VNFPerformanceManagementNotification-API/PerformanceManagementNotification.robot
delete mode 100644 SOL003/VNFPerformanceManagementNotification-API/SOL003-VNFPerformanceManagement-API.json
delete mode 100644 SOL003/VNFPerformanceManagementNotification-API/environment/variables.txt
delete mode 100644 SOL003/VNFPerformanceManagementNotification-API/schemas/ProblemDetails.schema.json
create mode 100644 SOL005/NSDManagement-API/NSDManagementKeywords.robot
create mode 100644 SOL005/NSPerformanceManagement-API/NSPerformanceManagementKeywords.robot
diff --git a/SOL003/VNFIndicatorNotification-API/VnfIndicatorNotification.robot b/SOL003/VNFIndicator-API/VnfIndicatorNotification.robot
similarity index 100%
rename from SOL003/VNFIndicatorNotification-API/VnfIndicatorNotification.robot
rename to SOL003/VNFIndicator-API/VnfIndicatorNotification.robot
diff --git a/SOL003/VNFIndicator-API/environment/variables.txt b/SOL003/VNFIndicator-API/environment/variables.txt
index 5b76feb2..3bfdf323 100644
--- a/SOL003/VNFIndicator-API/environment/variables.txt
+++ b/SOL003/VNFIndicator-API/environment/variables.txt
@@ -23,5 +23,6 @@ ${callback_port} 9091
${callback_uri} http://172.22.1.7:${callback_port}
${callback_endpoint} /vnfind/subscriptions
${callback_endpoint_error} /subs_404
-
+${total_polling_time} 2 min
+${polling_interval} 10 sec
${MOCK_SERVER_JAR} ../../../bin/mockserver-netty-5.5.0-jar-with-dependencies.jar
\ No newline at end of file
diff --git a/SOL003/VNFIndicatorNotification-API/schemas/VnfIndicatorValueChangeNotification.schema.json b/SOL003/VNFIndicator-API/schemas/VnfIndicatorValueChangeNotification.schema.json
similarity index 100%
rename from SOL003/VNFIndicatorNotification-API/schemas/VnfIndicatorValueChangeNotification.schema.json
rename to SOL003/VNFIndicator-API/schemas/VnfIndicatorValueChangeNotification.schema.json
diff --git a/SOL003/VNFIndicatorNotification-API/environment/variables.txt b/SOL003/VNFIndicatorNotification-API/environment/variables.txt
deleted file mode 100644
index 6937bb28..00000000
--- a/SOL003/VNFIndicatorNotification-API/environment/variables.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-*** Variables ***
-${callback_port} 9091
-${callbackUri} http://172.22.1.7:${callback_port}
-${callback_endpoint} /vnfind/subscriptions
-${callback_endpoint_error} /subs_404
-${total_polling_time} 2 min
-${polling_interval} 10 sec
-${MOCK_SERVER_JAR} ../../../bin/mockserver-netty-5.5.0-jar-with-dependencies.jar
\ No newline at end of file
diff --git a/SOL003/VNFIndicatorNotification-API/schemas/ProblemDetails.schema.json b/SOL003/VNFIndicatorNotification-API/schemas/ProblemDetails.schema.json
deleted file mode 100644
index 2af3ef9b..00000000
--- a/SOL003/VNFIndicatorNotification-API/schemas/ProblemDetails.schema.json
+++ /dev/null
@@ -1 +0,0 @@
-{ "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" } }}
\ No newline at end of file
diff --git a/SOL003/VNFPackageManagementNotification-API/PackageManagementNotification.robot b/SOL003/VNFPackageManagement-API/PackageManagementNotification.robot
similarity index 100%
rename from SOL003/VNFPackageManagementNotification-API/PackageManagementNotification.robot
rename to SOL003/VNFPackageManagement-API/PackageManagementNotification.robot
diff --git a/SOL003/VNFPackageManagement-API/VNFPackageManagementKeywords.robot b/SOL003/VNFPackageManagement-API/VNFPackageManagementKeywords.robot
index 8889a3fd..dcaa1ca3 100644
--- a/SOL003/VNFPackageManagement-API/VNFPackageManagementKeywords.robot
+++ b/SOL003/VNFPackageManagement-API/VNFPackageManagementKeywords.robot
@@ -137,7 +137,6 @@ Check HTTP Response Body Matches the Subscription
Should Be Equal ${response['body']['callbackUri']} ${subscription['callbackUri']}
-
Check Postcondition VNF Package Subscription Is Set
[Arguments] ${location}=""
Log Check Postcondition subscription exist
diff --git a/SOL003/VNFPackageManagement-API/environment/variables.txt b/SOL003/VNFPackageManagement-API/environment/variables.txt
index 486125ee..519c77a6 100644
--- a/SOL003/VNFPackageManagement-API/environment/variables.txt
+++ b/SOL003/VNFPackageManagement-API/environment/variables.txt
@@ -27,6 +27,6 @@ ${callback_port} 9091
${callback_uri} http://172.22.1.7:${callback_port}
${callback_endpoint} /vnfpkgm/subscriptions
${callback_endpoint_error} /subs_404
-${sleep_interval} 20s
-
+${total_polling_time} 2 min
+${polling_interval} 10 sec
${MOCK_SERVER_JAR} ../../../bin/mockserver-netty-5.5.0-jar-with-dependencies.jar
\ No newline at end of file
diff --git a/SOL003/VNFPackageManagementNotification-API/schemas/PackageChangeNotification.schema.json b/SOL003/VNFPackageManagement-API/schemas/PackageChangeNotification.schema.json
similarity index 100%
rename from SOL003/VNFPackageManagementNotification-API/schemas/PackageChangeNotification.schema.json
rename to SOL003/VNFPackageManagement-API/schemas/PackageChangeNotification.schema.json
diff --git a/SOL003/VNFPackageManagementNotification-API/schemas/PackageOnboardingNotification.schema.json b/SOL003/VNFPackageManagement-API/schemas/PackageOnboardingNotification.schema.json
similarity index 100%
rename from SOL003/VNFPackageManagementNotification-API/schemas/PackageOnboardingNotification.schema.json
rename to SOL003/VNFPackageManagement-API/schemas/PackageOnboardingNotification.schema.json
diff --git a/SOL003/VNFPackageManagementNotification-API/environment/variables.txt b/SOL003/VNFPackageManagementNotification-API/environment/variables.txt
deleted file mode 100644
index 5788c989..00000000
--- a/SOL003/VNFPackageManagementNotification-API/environment/variables.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-*** Variables ***
-${callback_port} 9091
-${callback_uri} http://172.22.1.7:${callback_port}
-${callback_endpoint} /vnfpkgm/subscriptions
-${callback_endpoint_error} /subs_404
-${total_polling_time} 2 min
-${polling_interval} 10 sec
-${MOCK_SERVER_JAR} ../../../bin/mockserver-netty-5.5.0-jar-with-dependencies.jar
\ No newline at end of file
diff --git a/SOL003/VNFPackageManagementNotification-API/schemas/ProblemDetails.schema.json b/SOL003/VNFPackageManagementNotification-API/schemas/ProblemDetails.schema.json
deleted file mode 100644
index 2af3ef9b..00000000
--- a/SOL003/VNFPackageManagementNotification-API/schemas/ProblemDetails.schema.json
+++ /dev/null
@@ -1 +0,0 @@
-{ "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" } }}
\ No newline at end of file
diff --git a/SOL003/VNFPerformanceManagement-API/PerformanceManagementNotification.robot b/SOL003/VNFPerformanceManagement-API/PerformanceManagementNotification.robot
index 099a2d29..7fc29c18 100644
--- a/SOL003/VNFPerformanceManagement-API/PerformanceManagementNotification.robot
+++ b/SOL003/VNFPerformanceManagement-API/PerformanceManagementNotification.robot
@@ -8,15 +8,7 @@ Library Collections
Library String
-*** Keywords ***
-Check Notification Endpoint
- &{req}= Create Mock Request Matcher GET ${callback_endpoint}
- &{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 ${callback_endpoint}
-
+*** Test Cases ***
Post Performance Information Available Notification
${json}= Get File schemas/PerformanceInformationAvailableNotification.schema.json
${BODY}= evaluate json.loads('''${json}''') json
@@ -24,7 +16,7 @@ Post Performance Information Available Notification
&{req}= Create Mock Request Matcher POST ${callback_endpoint} 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}
+ Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
Log Verifying results
Verify Mock Expectation ${req}
Log Cleaning the endpoint
@@ -38,7 +30,7 @@ Post Performance Information Available Notification Negative 404
&{req}= Create Mock Request Matcher POST ${callback_endpoint_error} body_type="JSON_SCHEMA" body=${BODY}
&{rsp}= Create Mock Response headers="Content-Type: application/json" status_code=404
Create Mock Expectation ${req} ${rsp}
- Sleep ${sleep_interval}
+ Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
Log Verifying results
Verify Mock Expectation ${req}
Log Cleaning the endpoint
@@ -51,7 +43,7 @@ Post Threshold Crossed Notification
&{req}= Create Mock Request Matcher POST ${callback_endpoint} 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}
+ Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
Log Verifying results
Verify Mock Expectation ${req}
Log Cleaning the endpoint
@@ -65,7 +57,7 @@ Post Threshold Crossed Notification Negative 404
&{req}= Create Mock Request Matcher POST ${callback_endpoint_error} body_type="JSON_SCHEMA" body=${BODY}
&{rsp}= Create Mock Response headers="Content-Type: application/json" status_code=404
Create Mock Expectation ${req} ${rsp}
- Sleep ${sleep_interval}
+ Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
Log Verifying results
Verify Mock Expectation ${req}
Log Cleaning the endpoint
@@ -77,7 +69,7 @@ PUT Performance Notification
&{req}= Create Mock Request Matcher PUT ${callback_endpoint}
&{rsp}= Create Mock Response status_code=405
Create Mock Expectation ${req} ${rsp}
- Sleep ${sleep_interval}
+ Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
Log Verifying results
Verify Mock Expectation ${req}
Log Cleaning the endpoint
@@ -89,7 +81,7 @@ PATCH Performance Notification
&{req}= Create Mock Request Matcher PATCH ${callback_endpoint}
&{rsp}= Create Mock Response status_code=405
Create Mock Expectation ${req} ${rsp}
- Sleep ${sleep_interval}
+ Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
Log Verifying results
Verify Mock Expectation ${req}
Log Cleaning the endpoint
@@ -101,15 +93,15 @@ DELETE Performance Notification
&{req}= Create Mock Request Matcher DELETE ${callback_endpoint}
&{rsp}= Create Mock Response status_code=405
Create Mock Expectation ${req} ${rsp}
- Sleep ${sleep_interval}
+ Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
Log Verifying results
Verify Mock Expectation ${req}
Log Cleaning the endpoint
Clear Requests ${callback_endpoint}
+*** Keywords ***
Create Sessions
- Pass Execution If ${VNFM_CHECKS_NOTIF_ENDPOINT} == 0 VNFM is not checking notification endpoint.
Start Process java -jar ${MOCK_SERVER_JAR} -serverPort ${callback_port} alias=mockInstance
Wait For Process handle=mockInstance timeout=5s on_timeout=continue
- Create Mock Session ${callback_uri}
\ No newline at end of file
+ Create Mock Session ${callback_uri}:${callback_port}
\ No newline at end of file
diff --git a/SOL003/VNFPerformanceManagement-API/VNFPerformanceManagementKeywords.robot b/SOL003/VNFPerformanceManagement-API/VNFPerformanceManagementKeywords.robot
index a7c7ade1..fc50b933 100644
--- a/SOL003/VNFPerformanceManagement-API/VNFPerformanceManagementKeywords.robot
+++ b/SOL003/VNFPerformanceManagement-API/VNFPerformanceManagementKeywords.robot
@@ -295,6 +295,7 @@ Check HTTP Response Body Matches the Subscription
Check Postcondition VNF Performance Subscription Is Set
Log Check Postcondition subscription exist
Set Headers {"Accept": "${ACCEPT_JSON}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${response['body']['id']}
${output}= Output response
Set Suite Variable ${response} ${output}
@@ -302,6 +303,7 @@ Check Postcondition VNF Performance Subscription Is Set
Check Postcondition Subscription Resource URI Returned in Location Header Is Valid
Log Going to check postcondition
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
GET ${response.headers['Location']}
Integer response status 200
Log Received a 200 OK as expected
diff --git a/SOL003/VNFPerformanceManagement-API/environment/variables.txt b/SOL003/VNFPerformanceManagement-API/environment/variables.txt
index c73d2848..553e63e5 100644
--- a/SOL003/VNFPerformanceManagement-API/environment/variables.txt
+++ b/SOL003/VNFPerformanceManagement-API/environment/variables.txt
@@ -25,4 +25,7 @@ ${callback_endpoint} /vnfpm/subscriptions
${callback_endpoint_error} /subs_404
${sleep_interval} 20s
+${total_polling_time} 2 min
+${polling_interval} 10 sec
+
${MOCK_SERVER_JAR} ../../../bin/mockserver-netty-5.5.0-jar-with-dependencies.jar
\ No newline at end of file
diff --git a/SOL003/VNFPerformanceManagementNotification-API/jsons/PerformanceInformationAvailableNotification.json b/SOL003/VNFPerformanceManagement-API/jsons/PerformanceInformationAvailableNotification.json
similarity index 96%
rename from SOL003/VNFPerformanceManagementNotification-API/jsons/PerformanceInformationAvailableNotification.json
rename to SOL003/VNFPerformanceManagement-API/jsons/PerformanceInformationAvailableNotification.json
index d40d3bfa..cbe45fa7 100644
--- a/SOL003/VNFPerformanceManagementNotification-API/jsons/PerformanceInformationAvailableNotification.json
+++ b/SOL003/VNFPerformanceManagement-API/jsons/PerformanceInformationAvailableNotification.json
@@ -1,13 +1,13 @@
-{
- "id": "id",
- "notificationType" : "PerformanceInformationAvailableNotification",
- "subscriptionId ": "subscriptionId",
- "timeStamp": "2012-04-21T18:25:43-05:00",
- "objectInstanceId": "vnfID",
- "_links": {
- "subscription": "link to subscription",
- "pmJob" : "link to PMJob",
- "performanceReport": "link to PerformanceReport"
- }
-
+{
+ "id": "id",
+ "notificationType" : "PerformanceInformationAvailableNotification",
+ "subscriptionId ": "subscriptionId",
+ "timeStamp": "2012-04-21T18:25:43-05:00",
+ "objectInstanceId": "vnfID",
+ "_links": {
+ "subscription": "link to subscription",
+ "pmJob" : "link to PMJob",
+ "performanceReport": "link to PerformanceReport"
+ }
+
}
\ No newline at end of file
diff --git a/SOL003/VNFPerformanceManagementNotification-API/jsons/ThresholdCrossedNotification.json b/SOL003/VNFPerformanceManagement-API/jsons/ThresholdCrossedNotification.json
similarity index 100%
rename from SOL003/VNFPerformanceManagementNotification-API/jsons/ThresholdCrossedNotification.json
rename to SOL003/VNFPerformanceManagement-API/jsons/ThresholdCrossedNotification.json
diff --git a/SOL003/VNFPerformanceManagementNotification-API/schemas/PerformanceInformationAvailableNotification.schema.json b/SOL003/VNFPerformanceManagement-API/schemas/PerformanceInformationAvailableNotification.schema.json
similarity index 97%
rename from SOL003/VNFPerformanceManagementNotification-API/schemas/PerformanceInformationAvailableNotification.schema.json
rename to SOL003/VNFPerformanceManagement-API/schemas/PerformanceInformationAvailableNotification.schema.json
index cdabf7b5..04ae7ead 100644
--- a/SOL003/VNFPerformanceManagementNotification-API/schemas/PerformanceInformationAvailableNotification.schema.json
+++ b/SOL003/VNFPerformanceManagement-API/schemas/PerformanceInformationAvailableNotification.schema.json
@@ -1,105 +1,105 @@
-{
- "description": "This notification informs the receiver that performance information is available. The timing of sending this notification is determined by the capability of the producing entity to evaluate the threshold crossing condition. The notification shall be triggered by the VNFM when new performance information collected by a PM job is available.\n",
- "type": "object",
- "required": [
- "id",
- "notificationType",
- "subscriptionId",
- "timeStamp",
- "objectInstanceId",
- "_links"
- ],
- "properties": {
- "id": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- },
- "notificationType": {
- "description": "Discriminator for the different notification types. Shall be set to \"PerformanceInformationAvailableNotification\" for this notification type.\n",
- "type": "string",
- "enum": [
- "PerformanceInformationAvailableNotification"
- ]
- },
- "subscriptionId": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- },
- "timeStamp": {
- "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n",
- "type": "string",
- "format": "date-time"
- },
- "objectInstanceId": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- },
- "_links": {
- "description": "Links to resources related to this notification.\n",
- "type": "object",
- "required": [
- "subscription",
- "pmJob",
- "performanceReport"
- ],
- "properties": {
- "subscription": {
- "description": "This type represents a link to a resource.\n",
- "type": "object",
- "required": [
- "href"
- ],
- "properties": {
- "href": {
- "description": "URI of the referenced resource.\n",
- "type": "string",
- "format": "url"
- }
- }
- },
- "objectInstance": {
- "description": "This type represents a link to a resource.\n",
- "type": "object",
- "required": [
- "href"
- ],
- "properties": {
- "href": {
- "description": "URI of the referenced resource.\n",
- "type": "string",
- "format": "url"
- }
- }
- },
- "pmJob": {
- "description": "This type represents a link to a resource.\n",
- "type": "object",
- "required": [
- "href"
- ],
- "properties": {
- "href": {
- "description": "URI of the referenced resource.\n",
- "type": "string",
- "format": "url"
- }
- }
- },
- "performanceReport": {
- "description": "This type represents a link to a resource.\n",
- "type": "object",
- "required": [
- "href"
- ],
- "properties": {
- "href": {
- "description": "URI of the referenced resource.\n",
- "type": "string",
- "format": "url"
- }
- }
- }
- }
- }
- }
+{
+ "description": "This notification informs the receiver that performance information is available. The timing of sending this notification is determined by the capability of the producing entity to evaluate the threshold crossing condition. The notification shall be triggered by the VNFM when new performance information collected by a PM job is available.\n",
+ "type": "object",
+ "required": [
+ "id",
+ "notificationType",
+ "subscriptionId",
+ "timeStamp",
+ "objectInstanceId",
+ "_links"
+ ],
+ "properties": {
+ "id": {
+ "description": "An identifier with the intention of being globally unique.\n",
+ "type": "string"
+ },
+ "notificationType": {
+ "description": "Discriminator for the different notification types. Shall be set to \"PerformanceInformationAvailableNotification\" for this notification type.\n",
+ "type": "string",
+ "enum": [
+ "PerformanceInformationAvailableNotification"
+ ]
+ },
+ "subscriptionId": {
+ "description": "An identifier with the intention of being globally unique.\n",
+ "type": "string"
+ },
+ "timeStamp": {
+ "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "objectInstanceId": {
+ "description": "An identifier with the intention of being globally unique.\n",
+ "type": "string"
+ },
+ "_links": {
+ "description": "Links to resources related to this notification.\n",
+ "type": "object",
+ "required": [
+ "subscription",
+ "pmJob",
+ "performanceReport"
+ ],
+ "properties": {
+ "subscription": {
+ "description": "This type represents a link to a resource.\n",
+ "type": "object",
+ "required": [
+ "href"
+ ],
+ "properties": {
+ "href": {
+ "description": "URI of the referenced resource.\n",
+ "type": "string",
+ "format": "url"
+ }
+ }
+ },
+ "objectInstance": {
+ "description": "This type represents a link to a resource.\n",
+ "type": "object",
+ "required": [
+ "href"
+ ],
+ "properties": {
+ "href": {
+ "description": "URI of the referenced resource.\n",
+ "type": "string",
+ "format": "url"
+ }
+ }
+ },
+ "pmJob": {
+ "description": "This type represents a link to a resource.\n",
+ "type": "object",
+ "required": [
+ "href"
+ ],
+ "properties": {
+ "href": {
+ "description": "URI of the referenced resource.\n",
+ "type": "string",
+ "format": "url"
+ }
+ }
+ },
+ "performanceReport": {
+ "description": "This type represents a link to a resource.\n",
+ "type": "object",
+ "required": [
+ "href"
+ ],
+ "properties": {
+ "href": {
+ "description": "URI of the referenced resource.\n",
+ "type": "string",
+ "format": "url"
+ }
+ }
+ }
+ }
+ }
+ }
}
\ No newline at end of file
diff --git a/SOL003/VNFPerformanceManagementNotification-API/schemas/ThresholdCrossedNotification.schema.json b/SOL003/VNFPerformanceManagement-API/schemas/ThresholdCrossedNotification.schema.json
similarity index 97%
rename from SOL003/VNFPerformanceManagementNotification-API/schemas/ThresholdCrossedNotification.schema.json
rename to SOL003/VNFPerformanceManagement-API/schemas/ThresholdCrossedNotification.schema.json
index b6f70e6a..e5cec230 100644
--- a/SOL003/VNFPerformanceManagementNotification-API/schemas/ThresholdCrossedNotification.schema.json
+++ b/SOL003/VNFPerformanceManagement-API/schemas/ThresholdCrossedNotification.schema.json
@@ -1,113 +1,113 @@
-{
- "description": "This type represents a notification that is sent when a threshold has been crossed. The notification shall be triggered by the VNFM when a threshold has been crossed.\n",
- "type": "object",
- "required": [
- "id",
- "notificationType",
- "subscriptionId",
- "timeStamp",
- "thresholdId",
- "crossingDirection",
- "objectInstanceId",
- "performanceMetric",
- "performanceValue",
- "_links"
- ],
- "properties": {
- "id": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- },
- "notificationType": {
- "description": "Discriminator for the different notification types. Shall be set to \"ThresholdCrossedNotification\" for this notification type.\n",
- "type": "string",
- "enum": [
- "ThresholdCrossedNotification"
- ]
- },
- "subscriptionId": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- },
- "timeStamp": {
- "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n",
- "type": "string",
- "format": "date-time"
- },
- "thresholdId": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- },
- "crossingDirection": {
- "type": "string",
- "enum": [
- "UP",
- "DOWN"
- ]
- },
- "objectInstanceId": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- },
- "performanceMetric": {
- "description": "Performance metric associated with the threshold.\n",
- "type": "string"
- },
- "performanceValue": {
- "description": "Value of the metric that resulted in threshold crossing. The type of the \"performanceValue\" attribute (i.e. scalar, structure (Object in JSON), or array (of scalars, arrays or structures / Objects)) is assumed to be defined in the external measurement specification (see ETSI GS NFV-IFA 027).\n",
- "type": "object"
- },
- "_links": {
- "description": "Links to resources related to this notification.\n",
- "type": "object",
- "required": [
- "subscription",
- "threshold"
- ],
- "properties": {
- "subscription": {
- "description": "This type represents a link to a resource.\n",
- "type": "object",
- "required": [
- "href"
- ],
- "properties": {
- "href": {
- "description": "URI of the referenced resource.\n",
- "type": "string",
- "format": "url"
- }
- }
- },
- "objectInstance": {
- "description": "This type represents a link to a resource.\n",
- "type": "object",
- "required": [
- "href"
- ],
- "properties": {
- "href": {
- "description": "URI of the referenced resource.\n",
- "type": "string",
- "format": "url"
- }
- }
- },
- "threshold": {
- "description": "This type represents a link to a resource.\n",
- "type": "object",
- "required": [
- "href"
- ],
- "properties": {
- "href": {
- "description": "URI of the referenced resource.\n",
- "type": "string",
- "format": "url"
- }
- }
- }
- }
- }
- }
+{
+ "description": "This type represents a notification that is sent when a threshold has been crossed. The notification shall be triggered by the VNFM when a threshold has been crossed.\n",
+ "type": "object",
+ "required": [
+ "id",
+ "notificationType",
+ "subscriptionId",
+ "timeStamp",
+ "thresholdId",
+ "crossingDirection",
+ "objectInstanceId",
+ "performanceMetric",
+ "performanceValue",
+ "_links"
+ ],
+ "properties": {
+ "id": {
+ "description": "An identifier with the intention of being globally unique.\n",
+ "type": "string"
+ },
+ "notificationType": {
+ "description": "Discriminator for the different notification types. Shall be set to \"ThresholdCrossedNotification\" for this notification type.\n",
+ "type": "string",
+ "enum": [
+ "ThresholdCrossedNotification"
+ ]
+ },
+ "subscriptionId": {
+ "description": "An identifier with the intention of being globally unique.\n",
+ "type": "string"
+ },
+ "timeStamp": {
+ "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "thresholdId": {
+ "description": "An identifier with the intention of being globally unique.\n",
+ "type": "string"
+ },
+ "crossingDirection": {
+ "type": "string",
+ "enum": [
+ "UP",
+ "DOWN"
+ ]
+ },
+ "objectInstanceId": {
+ "description": "An identifier with the intention of being globally unique.\n",
+ "type": "string"
+ },
+ "performanceMetric": {
+ "description": "Performance metric associated with the threshold.\n",
+ "type": "string"
+ },
+ "performanceValue": {
+ "description": "Value of the metric that resulted in threshold crossing. The type of the \"performanceValue\" attribute (i.e. scalar, structure (Object in JSON), or array (of scalars, arrays or structures / Objects)) is assumed to be defined in the external measurement specification (see ETSI GS NFV-IFA 027).\n",
+ "type": "object"
+ },
+ "_links": {
+ "description": "Links to resources related to this notification.\n",
+ "type": "object",
+ "required": [
+ "subscription",
+ "threshold"
+ ],
+ "properties": {
+ "subscription": {
+ "description": "This type represents a link to a resource.\n",
+ "type": "object",
+ "required": [
+ "href"
+ ],
+ "properties": {
+ "href": {
+ "description": "URI of the referenced resource.\n",
+ "type": "string",
+ "format": "url"
+ }
+ }
+ },
+ "objectInstance": {
+ "description": "This type represents a link to a resource.\n",
+ "type": "object",
+ "required": [
+ "href"
+ ],
+ "properties": {
+ "href": {
+ "description": "URI of the referenced resource.\n",
+ "type": "string",
+ "format": "url"
+ }
+ }
+ },
+ "threshold": {
+ "description": "This type represents a link to a resource.\n",
+ "type": "object",
+ "required": [
+ "href"
+ ],
+ "properties": {
+ "href": {
+ "description": "URI of the referenced resource.\n",
+ "type": "string",
+ "format": "url"
+ }
+ }
+ }
+ }
+ }
+ }
}
\ No newline at end of file
diff --git a/SOL003/VNFPerformanceManagementNotification-API/PerformanceManagementNotification.robot b/SOL003/VNFPerformanceManagementNotification-API/PerformanceManagementNotification.robot
deleted file mode 100644
index 7fc29c18..00000000
--- a/SOL003/VNFPerformanceManagementNotification-API/PerformanceManagementNotification.robot
+++ /dev/null
@@ -1,107 +0,0 @@
-*** Setting ***
-Resource environment/variables.txt
-Library MockServerLibrary
-Library Process
-Library OperatingSystem
-Library BuiltIn
-Library Collections
-Library String
-
-
-*** Test Cases ***
-Post Performance Information Available Notification
- ${json}= Get File schemas/PerformanceInformationAvailableNotification.schema.json
- ${BODY}= evaluate json.loads('''${json}''') json
- Log Creating mock request and response to handle Performance Information Available Notification
- &{req}= Create Mock Request Matcher POST ${callback_endpoint} body_type="JSON_SCHEMA" body=${BODY}
- &{rsp}= Create Mock Response headers="Content-Type: application/json" status_code=204
- Create Mock Expectation ${req} ${rsp}
- Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
- Log Verifying results
- Verify Mock Expectation ${req}
- Log Cleaning the endpoint
- Clear Requests ${callback_endpoint}
-
-
-Post Performance Information Available Notification Negative 404
- ${json}= Get File schemas/ProblemDetails.schema.json
- ${BODY}= evaluate json.loads('''${json}''') json
- Log Creating mock request and response to handle Performance Information Available Notification to handle 404 error
- &{req}= Create Mock Request Matcher POST ${callback_endpoint_error} body_type="JSON_SCHEMA" body=${BODY}
- &{rsp}= Create Mock Response headers="Content-Type: application/json" status_code=404
- Create Mock Expectation ${req} ${rsp}
- Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
- Log Verifying results
- Verify Mock Expectation ${req}
- Log Cleaning the endpoint
- Clear Requests ${callback_endpoint}
-
-Post Threshold Crossed Notification
- ${json}= Get File schema/ThresholdCrossedNotification.schema.json
- ${BODY}= evaluate json.loads('''${json}''') json
- Log Creating mock request and response to handle Threshold Crossed Notification
- &{req}= Create Mock Request Matcher POST ${callback_endpoint} body_type="JSON_SCHEMA" body=${BODY}
- &{rsp}= Create Mock Response headers="Content-Type: application/json" status_code=204
- Create Mock Expectation ${req} ${rsp}
- Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
- Log Verifying results
- Verify Mock Expectation ${req}
- Log Cleaning the endpoint
- Clear Requests ${callback_endpoint}
-
-
-Post Threshold Crossed Notification Negative 404
- ${json}= Get File schemas/ProblemDetails.schema.json
- ${BODY}= evaluate json.loads('''${json}''') json
- Log Creating mock request and response to handleThreshold Crossed Notification to handle 404 error
- &{req}= Create Mock Request Matcher POST ${callback_endpoint_error} body_type="JSON_SCHEMA" body=${BODY}
- &{rsp}= Create Mock Response headers="Content-Type: application/json" status_code=404
- Create Mock Expectation ${req} ${rsp}
- Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
- Log Verifying results
- Verify Mock Expectation ${req}
- Log Cleaning the endpoint
- Clear Requests ${callback_endpoint}
-
-
-PUT Performance Notification
- Log PUT Method not implemented
- &{req}= Create Mock Request Matcher PUT ${callback_endpoint}
- &{rsp}= Create Mock Response status_code=405
- Create Mock Expectation ${req} ${rsp}
- Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
- Log Verifying results
- Verify Mock Expectation ${req}
- Log Cleaning the endpoint
- Clear Requests ${callback_endpoint}
-
-
-PATCH Performance Notification
- Log PATCH Method not implemented
- &{req}= Create Mock Request Matcher PATCH ${callback_endpoint}
- &{rsp}= Create Mock Response status_code=405
- Create Mock Expectation ${req} ${rsp}
- Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
- Log Verifying results
- Verify Mock Expectation ${req}
- Log Cleaning the endpoint
- Clear Requests ${callback_endpoint}
-
-
-DELETE Performance Notification
- Log PATCH Method not implemented
- &{req}= Create Mock Request Matcher DELETE ${callback_endpoint}
- &{rsp}= Create Mock Response status_code=405
- Create Mock Expectation ${req} ${rsp}
- Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
- Log Verifying results
- Verify Mock Expectation ${req}
- Log Cleaning the endpoint
- Clear Requests ${callback_endpoint}
-
-
-*** Keywords ***
-Create Sessions
- Start Process java -jar ${MOCK_SERVER_JAR} -serverPort ${callback_port} alias=mockInstance
- Wait For Process handle=mockInstance timeout=5s on_timeout=continue
- Create Mock Session ${callback_uri}:${callback_port}
\ No newline at end of file
diff --git a/SOL003/VNFPerformanceManagementNotification-API/SOL003-VNFPerformanceManagement-API.json b/SOL003/VNFPerformanceManagementNotification-API/SOL003-VNFPerformanceManagement-API.json
deleted file mode 100644
index daff5a88..00000000
--- a/SOL003/VNFPerformanceManagementNotification-API/SOL003-VNFPerformanceManagement-API.json
+++ /dev/null
@@ -1,5545 +0,0 @@
-{
- "swagger": "2.0",
- "info": {
- "version": "1.1.1",
- "title": "SOL003 - VNF Performance Management interface",
- "description": "SOL003 - VNF Performance Management interface\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\nIn clause 4.3.2 of ETSI GS NFV-SOL 003 v2.4.1, an attribute-based filtering mechanism is defined. This mechanism is currently not included in the corresponding OpenAPI design for this GS version. Changes to the attribute-based filtering mechanism are being considered in v2.5.1 of this GS for inclusion in the corresponding future ETSI NFV OpenAPI design.\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 003 V2.4.1",
- "url": "http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.04.01_60/gs_NFV-SOL003v020401p.pdf"
- },
- "basePath": "/vnfpm/v1",
- "schemes": ["https"],
- "consumes": ["application/json"],
- "produces": ["application/json"],
- "paths": {
- "/pm_jobs": {
- "post": {
- "description": "Create PM Job\n\nThe POST method creates a PM job.\n",
- "parameters": [{
- "name": "CreatePmJobRequest",
- "description": "The VNF creation parameters",
- "in": "body",
- "required": true,
- "schema": {
- "description": "This type represents a request to create a PM job.\n",
- "type": "object",
- "required": ["criteria"],
- "properties": {
- "objectInstanceIds": {
- "description": "Identifiers of the VNF instances for which performance information is requested to be collected.\n",
- "type": "array",
- "items": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- }
- },
- "criteria": {
- "description": "Criteria of the collection of performance information.\n",
- "type": "object",
- "required": ["collectionPeriod", "reportingPeriod"],
- "properties": {
- "performanceMetric": {
- "description": "This defines the types of performance metrics for the specified object instances, as specified in ETSI GS NFV-IFA 027). At least one of the two attributes (performance metric or group) shall be present.\n",
- "type": "array",
- "items": {
- "type": "string"
- }
- },
- "performanceMetricGroup": {
- "description": "Group of performance metrics. A metric group is a pre-defined list of metrics, known to the producer that it can decompose to individual metrics. At least one of the two attributes (performance metric or group) shall be present.\n",
- "type": "array",
- "items": {
- "type": "string"
- }
- },
- "collectionPeriod": {
- "description": "Specifies the periodicity at which the producer will collect performance information. The unit shall be seconds. At the end of each reportingPeriod, the producer will inform the consumer about availability of the performance data collected for each completed collection period during this reportingPeriod. The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance data for the collection periods within one reporting period are reported together.\n",
- "type": "integer"
- },
- "reportingPeriod": {
- "description": "Specifies the periodicity at which the producer will report to the consumer. about performance information. The unit shall be seconds. At the end of each reportingPeriod, the producer will inform the consumer about availability of the performance data collected for each completed collection period during this reportingPeriod. The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance data for the collection periods within one reporting period are reported together.\n",
- "type": "integer"
- },
- "reportingBoundary": {
- "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n",
- "type": "string",
- "format": "date-time"
- }
- }
- }
- }
- }
- }, {
- "name": "Accept",
- "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n",
- "in": "header",
- "required": true,
- "type": "string"
- }, {
- "name": "Content-Type",
- "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n",
- "in": "header",
- "required": true,
- "type": "string"
- }, {
- "name": "Authorization",
- "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
- "in": "header",
- "required": false,
- "type": "string"
- }],
- "responses": {
- "201": {
- "description": "Created\nThe PM job was created successfully. The response body shall contain a representation of the created PM job resource. The HTTP response shall include a \"Location\" HTTP header that points to the created PM job resource.\n",
- "headers": {
- "Location": {
- "description": "The resource URI of the created PM Job",
- "type": "string",
- "format": "url"
- },
- "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": "This type represents a PM job.\n",
- "type": "object",
- "required": ["id", "objectInstanceIds", "criteria"],
- "properties": {
- "id": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- },
- "objectInstanceIds": {
- "description": "Identifiers of the VNF instances for which performance information is collected.\n",
- "type": "array",
- "items": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- }
- },
- "criteria": {
- "description": "Criteria of the collection of performance information.\n",
- "type": "object",
- "required": ["collectionPeriod", "reportingPeriod"],
- "properties": {
- "performanceMetric": {
- "description": "This defines the types of performance metrics for the specified object instances, as specified in ETSI GS NFV-IFA 027). At least one of the two attributes (performance metric or group) shall be present.\n",
- "type": "array",
- "items": {
- "type": "string"
- }
- },
- "performanceMetricGroup": {
- "description": "Group of performance metrics. A metric group is a pre-defined list of metrics, known to the producer that it can decompose to individual metrics. At least one of the two attributes (performance metric or group) shall be present.\n",
- "type": "array",
- "items": {
- "type": "string"
- }
- },
- "collectionPeriod": {
- "description": "Specifies the periodicity at which the producer will collect performance information. The unit shall be seconds. At the end of each reportingPeriod, the producer will inform the consumer about availability of the performance data collected for each completed collection period during this reportingPeriod. The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance data for the collection periods within one reporting period are reported together.\n",
- "type": "integer"
- },
- "reportingPeriod": {
- "description": "Specifies the periodicity at which the producer will report to the consumer. about performance information. The unit shall be seconds. At the end of each reportingPeriod, the producer will inform the consumer about availability of the performance data collected for each completed collection period during this reportingPeriod. The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance data for the collection periods within one reporting period are reported together.\n",
- "type": "integer"
- },
- "reportingBoundary": {
- "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n",
- "type": "string",
- "format": "date-time"
- }
- }
- },
- "reports": {
- "description": "Information about available reports collected by this PM job.\n",
- "type": "object",
- "required": ["href", "readyTime", "_links"],
- "properties": {
- "href": {
- "description": "The Uri where the report can be obtained.\n",
- "type": "string",
- "format": "url"
- },
- "readyTime": {
- "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n",
- "type": "string",
- "format": "date-time"
- },
- "expiryTime": {
- "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n",
- "type": "string",
- "format": "date-time"
- },
- "fileSize": {
- "description": "The size of the report file in bytes, if known.\n",
- "type": "integer"
- },
- "_links": {
- "description": "Links for this resource.\n",
- "type": "object",
- "required": ["self"],
- "properties": {
- "self": {
- "description": "This type represents a link to a resource.\n",
- "type": "object",
- "required": ["href"],
- "properties": {
- "href": {
- "description": "URI of the referenced resource.\n",
- "type": "string",
- "format": "url"
- }
- }
- },
- "objects": {
- "description": "Links to resources representing the VNF instances for which performance information is collected. Shall be present if the VNF instance information is accessible as a resource.\n",
- "type": "array",
- "items": {
- "description": "This type represents a link to a resource.\n",
- "type": "object",
- "required": ["href"],
- "properties": {
- "href": {
- "description": "URI of the referenced resource.\n",
- "type": "string",
- "format": "url"
- }
- }
- }
- }
- }
- }
- }
- }
- }
- }
- },
- "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. 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.\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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- }
- }
- },
- "get": {
- "description": "Query PM Job\n\nThe client can use this method to retrieve information about PM jobs.\n",
- "parameters": [{
- "name": "Accept",
- "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n",
- "in": "header",
- "required": true,
- "type": "string"
- }, {
- "name": "Authorization",
- "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
- "in": "header",
- "required": false,
- "type": "string"
- }],
- "responses": {
- "200": {
- "description": "OK\nInformation about zero or more PM jobs was queried successfully. The response body shall contain representations of zero or more PM jobs.\n",
- "headers": {
- "Content-Type": {
- "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n",
- "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": {
- "type": "array",
- "items": {
- "description": "This type represents a PM job.\n",
- "type": "object",
- "required": ["id", "objectInstanceIds", "criteria"],
- "properties": {
- "id": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- },
- "objectInstanceIds": {
- "description": "Identifiers of the VNF instances for which performance information is collected.\n",
- "type": "array",
- "items": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- }
- },
- "criteria": {
- "description": "Criteria of the collection of performance information.\n",
- "type": "object",
- "required": ["collectionPeriod", "reportingPeriod"],
- "properties": {
- "performanceMetric": {
- "description": "This defines the types of performance metrics for the specified object instances, as specified in ETSI GS NFV-IFA 027). At least one of the two attributes (performance metric or group) shall be present.\n",
- "type": "array",
- "items": {
- "type": "string"
- }
- },
- "performanceMetricGroup": {
- "description": "Group of performance metrics. A metric group is a pre-defined list of metrics, known to the producer that it can decompose to individual metrics. At least one of the two attributes (performance metric or group) shall be present.\n",
- "type": "array",
- "items": {
- "type": "string"
- }
- },
- "collectionPeriod": {
- "description": "Specifies the periodicity at which the producer will collect performance information. The unit shall be seconds. At the end of each reportingPeriod, the producer will inform the consumer about availability of the performance data collected for each completed collection period during this reportingPeriod. The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance data for the collection periods within one reporting period are reported together.\n",
- "type": "integer"
- },
- "reportingPeriod": {
- "description": "Specifies the periodicity at which the producer will report to the consumer. about performance information. The unit shall be seconds. At the end of each reportingPeriod, the producer will inform the consumer about availability of the performance data collected for each completed collection period during this reportingPeriod. The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance data for the collection periods within one reporting period are reported together.\n",
- "type": "integer"
- },
- "reportingBoundary": {
- "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n",
- "type": "string",
- "format": "date-time"
- }
- }
- },
- "reports": {
- "description": "Information about available reports collected by this PM job.\n",
- "type": "object",
- "required": ["href", "readyTime", "_links"],
- "properties": {
- "href": {
- "description": "The Uri where the report can be obtained.\n",
- "type": "string",
- "format": "url"
- },
- "readyTime": {
- "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n",
- "type": "string",
- "format": "date-time"
- },
- "expiryTime": {
- "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n",
- "type": "string",
- "format": "date-time"
- },
- "fileSize": {
- "description": "The size of the report file in bytes, if known.\n",
- "type": "integer"
- },
- "_links": {
- "description": "Links for this resource.\n",
- "type": "object",
- "required": ["self"],
- "properties": {
- "self": {
- "description": "This type represents a link to a resource.\n",
- "type": "object",
- "required": ["href"],
- "properties": {
- "href": {
- "description": "URI of the referenced resource.\n",
- "type": "string",
- "format": "url"
- }
- }
- },
- "objects": {
- "description": "Links to resources representing the VNF instances for which performance information is collected. Shall be present if the VNF instance information is accessible as a resource.\n",
- "type": "array",
- "items": {
- "description": "This type represents a link to a resource.\n",
- "type": "object",
- "required": ["href"],
- "properties": {
- "href": {
- "description": "URI of the referenced resource.\n",
- "type": "string",
- "format": "url"
- }
- }
- }
- }
- }
- }
- }
- }
- }
- }
- }
- },
- "400": {
- "description": "Bad Request\nInvalid attribute-based filtering parameters or Invalid attribute selector. It fhe 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.\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"
- }
- },
- "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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- }
- }
- }
- },
- "/pm_jobs/{pmJobId}": {
- "parameters": [{
- "name": "pmJobId",
- "description": "Identifier of the PM job. This identifier can be retrieved from the resource referenced by the \"Location\" HTTP header in the response to a POST request creating a new PM job resource. It can also be retrieved from the \"id\" attribute in the payload body of that response.\n",
- "in": "path",
- "type": "string",
- "required": true
- }],
- "get": {
- "description": "Query PM Job\n\nThe client can use this method for reading an individual PM job.\n",
- "parameters": [{
- "name": "Accept",
- "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n",
- "in": "header",
- "required": true,
- "type": "string"
- }, {
- "name": "Authorization",
- "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
- "in": "header",
- "required": false,
- "type": "string"
- }],
- "responses": {
- "200": {
- "description": "OK\nInformation about an individual PM job was queried successfully. The response body shall contain a representation of the PM job resource.\n",
- "headers": {
- "Content-Type": {
- "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n",
- "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": "This type represents a PM job.\n",
- "type": "object",
- "required": ["id", "objectInstanceIds", "criteria"],
- "properties": {
- "id": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- },
- "objectInstanceIds": {
- "description": "Identifiers of the VNF instances for which performance information is collected.\n",
- "type": "array",
- "items": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- }
- },
- "criteria": {
- "description": "Criteria of the collection of performance information.\n",
- "type": "object",
- "required": ["collectionPeriod", "reportingPeriod"],
- "properties": {
- "performanceMetric": {
- "description": "This defines the types of performance metrics for the specified object instances, as specified in ETSI GS NFV-IFA 027). At least one of the two attributes (performance metric or group) shall be present.\n",
- "type": "array",
- "items": {
- "type": "string"
- }
- },
- "performanceMetricGroup": {
- "description": "Group of performance metrics. A metric group is a pre-defined list of metrics, known to the producer that it can decompose to individual metrics. At least one of the two attributes (performance metric or group) shall be present.\n",
- "type": "array",
- "items": {
- "type": "string"
- }
- },
- "collectionPeriod": {
- "description": "Specifies the periodicity at which the producer will collect performance information. The unit shall be seconds. At the end of each reportingPeriod, the producer will inform the consumer about availability of the performance data collected for each completed collection period during this reportingPeriod. The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance data for the collection periods within one reporting period are reported together.\n",
- "type": "integer"
- },
- "reportingPeriod": {
- "description": "Specifies the periodicity at which the producer will report to the consumer. about performance information. The unit shall be seconds. At the end of each reportingPeriod, the producer will inform the consumer about availability of the performance data collected for each completed collection period during this reportingPeriod. The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance data for the collection periods within one reporting period are reported together.\n",
- "type": "integer"
- },
- "reportingBoundary": {
- "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n",
- "type": "string",
- "format": "date-time"
- }
- }
- },
- "reports": {
- "description": "Information about available reports collected by this PM job.\n",
- "type": "object",
- "required": ["href", "readyTime", "_links"],
- "properties": {
- "href": {
- "description": "The Uri where the report can be obtained.\n",
- "type": "string",
- "format": "url"
- },
- "readyTime": {
- "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n",
- "type": "string",
- "format": "date-time"
- },
- "expiryTime": {
- "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n",
- "type": "string",
- "format": "date-time"
- },
- "fileSize": {
- "description": "The size of the report file in bytes, if known.\n",
- "type": "integer"
- },
- "_links": {
- "description": "Links for this resource.\n",
- "type": "object",
- "required": ["self"],
- "properties": {
- "self": {
- "description": "This type represents a link to a resource.\n",
- "type": "object",
- "required": ["href"],
- "properties": {
- "href": {
- "description": "URI of the referenced resource.\n",
- "type": "string",
- "format": "url"
- }
- }
- },
- "objects": {
- "description": "Links to resources representing the VNF instances for which performance information is collected. Shall be present if the VNF instance information is accessible as a resource.\n",
- "type": "array",
- "items": {
- "description": "This type represents a link to a resource.\n",
- "type": "object",
- "required": ["href"],
- "properties": {
- "href": {
- "description": "URI of the referenced resource.\n",
- "type": "string",
- "format": "url"
- }
- }
- }
- }
- }
- }
- }
- }
- }
- }
- },
- "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. 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.\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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- }
- }
- },
- "delete": {
- "description": "Delete PM Job\n\nThis method terminates an individual PM job.\n",
- "parameters": [{
- "name": "Authorization",
- "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
- "in": "header",
- "required": false,
- "type": "string"
- }],
- "responses": {
- "204": {
- "description": "No Content\nThe PM job was deleted successfully. The response body shall be empty.\n",
- "headers": {
- "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
- }
- }
- },
- "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. 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.\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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- }
- }
- }
- },
- "/pm_jobs/{pmJobId}/reports/{reportId}": {
- "parameters": [{
- "name": "pmJobId",
- "description": "Identifier of the PM job.\n",
- "in": "path",
- "type": "string",
- "required": true
- }, {
- "name": "reportId",
- "description": "Identifier of the performance report.\n",
- "in": "path",
- "type": "string",
- "required": true
- }],
- "get": {
- "description": "The client can use this method for reading an individual performance report.\n",
- "parameters": [{
- "name": "Accept",
- "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n",
- "in": "header",
- "required": true,
- "type": "string"
- }, {
- "name": "Authorization",
- "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
- "in": "header",
- "required": false,
- "type": "string"
- }],
- "responses": {
- "200": {
- "description": "OK\nInformation of an individual performance report was read successfully. The response body shall contain a representation of the performance report resource.\n",
- "headers": {
- "Content-Type": {
- "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n",
- "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": "This type defines the format of a performance report provided by the VNFM to the NFVO as a result of collecting performance information as part of a PM job.\n",
- "type": "object",
- "properties": {
- "entries": {
- "description": "List of performance information entries. Each performance report entry is for a given metric of a given object (i.e. VNF instance), but can include multiple collected values.\n",
- "type": "array",
- "items": {
- "type": "object",
- "required": ["objectType", "objectInstanceId", "performanceMetric", "performanceValue"],
- "properties": {
- "objectType": {
- "description": "Defines the object type for which performance information is reported (i.e. VNF type). The string value shall be set to the vnfdId of the VNF instance to which the performance information relates.\n",
- "type": "string"
- },
- "objectInstanceId": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- },
- "performanceMetric": {
- "description": "Name of the metric collected.\n",
- "type": "string"
- },
- "performanceValues": {
- "description": "List of performance values with associated timestamp.\n",
- "type": "array",
- "items": {
- "type": "object",
- "required": ["timeStamp", "performanceValue"],
- "properties": {
- "timeStamp": {
- "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n",
- "type": "string",
- "format": "date-time"
- },
- "value": {
- "description": "Value of the metric collected. The type of the \"value\" attribute (i.e. scalar, structure (Object in JSON), or array (of scalars, arrays or structures / Objects)) is assumed to be defined in the external measurement specification (see ETSI GS NFV-IFA 027).\n",
- "type": "object"
- }
- }
- }
- }
- }
- }
- }
- }
- }
- },
- "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. 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.\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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- }
- }
- }
- },
- "/thresholds": {
- "post": {
- "description": "Create Threshold\n\nThe POST method can be used by the client to create a threshold.\n",
- "parameters": [{
- "name": "CreateThresholdRequest",
- "description": "Request parameters to create a threshold resource.\n",
- "in": "body",
- "required": true,
- "schema": {
- "description": "This type represents a request to create a threshold.\n",
- "type": "object",
- "required": ["objectInstanceId", "criteria"],
- "properties": {
- "objectInstanceId": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- },
- "criteria": {
- "description": "This type represents criteria that define a threshold.\n",
- "type": "object",
- "required": ["performanceMetric", "thresholdType"],
- "properties": {
- "performanceMetric": {
- "description": "Defines the performance metric associated with the threshold, as specified in ETSI GS NFV-IFA 027).\n",
- "type": "string"
- },
- "thresholdType": {
- "description": "Type of threshold. This attribute determines which other attributes are present in the data structure. Permitted values: * SIMPLE: Single-valued static threshold In the present document, simple thresholds are defined. The definition of additional threshold types is left for future specification.\n",
- "type": "string",
- "enum": ["SIMPLE"]
- },
- "simpleThresholdDetails": {
- "description": "Details of a simple threshold. Shall be present if thresholdType=\"SIMPLE\".\n",
- "type": "object",
- "required": ["thresholdValue", "hysteresis"],
- "properties": {
- "thresholdValue": {
- "description": "The threshold value. Shall be represented as a floating point number.\n",
- "type": "integer"
- },
- "hysteresis": {
- "description": "The hysteresis of the threshold. Shall be represented as a non-negative floating point number. A notification with crossing direction \"UP\" will be generated if the measured value reaches or exceeds \"thresholdValue\" + \"hysteresis\". A notification with crossing direction \"DOWN\" will be generated if the measured value reaches or undercuts \"thresholdValue\" - \"hysteresis\". The hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or reject the request).\n",
- "type": "integer"
- }
- }
- }
- }
- }
- }
- }
- }, {
- "name": "Accept",
- "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n",
- "in": "header",
- "required": true,
- "type": "string"
- }, {
- "name": "Authorization",
- "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
- "in": "header",
- "required": false,
- "type": "string"
- }, {
- "name": "Content-Type",
- "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n",
- "in": "header",
- "required": true,
- "type": "string"
- }],
- "responses": {
- "201": {
- "description": "Created\nA threshold was created successfully. The response body shall contain a representation of the created threshold resource. The HTTP response shall include a \"Location\" HTTP header that contains the resource URI of the created threshold resource.\n",
- "headers": {
- "Location": {
- "description": "The resource URI of the created VNF instance",
- "type": "string",
- "format": "url"
- },
- "Content-Type": {
- "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n",
- "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": "This type represents a threshold.\n",
- "type": "object",
- "required": ["id", "objectInstanceId", "criteria", "_links"],
- "properties": {
- "id": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- },
- "objectInstanceId": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- },
- "criteria": {
- "description": "This type represents criteria that define a threshold.\n",
- "type": "object",
- "required": ["performanceMetric", "thresholdType"],
- "properties": {
- "performanceMetric": {
- "description": "Defines the performance metric associated with the threshold, as specified in ETSI GS NFV-IFA 027).\n",
- "type": "string"
- },
- "thresholdType": {
- "description": "Type of threshold. This attribute determines which other attributes are present in the data structure. Permitted values: * SIMPLE: Single-valued static threshold In the present document, simple thresholds are defined. The definition of additional threshold types is left for future specification.\n",
- "type": "string",
- "enum": ["SIMPLE"]
- },
- "simpleThresholdDetails": {
- "description": "Details of a simple threshold. Shall be present if thresholdType=\"SIMPLE\".\n",
- "type": "object",
- "required": ["thresholdValue", "hysteresis"],
- "properties": {
- "thresholdValue": {
- "description": "The threshold value. Shall be represented as a floating point number.\n",
- "type": "integer"
- },
- "hysteresis": {
- "description": "The hysteresis of the threshold. Shall be represented as a non-negative floating point number. A notification with crossing direction \"UP\" will be generated if the measured value reaches or exceeds \"thresholdValue\" + \"hysteresis\". A notification with crossing direction \"DOWN\" will be generated if the measured value reaches or undercuts \"thresholdValue\" - \"hysteresis\". The hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or reject the request).\n",
- "type": "integer"
- }
- }
- }
- }
- },
- "_links": {
- "description": "Links for this resource.\n",
- "type": "object",
- "required": ["self"],
- "properties": {
- "self": {
- "description": "This type represents a link to a resource.\n",
- "type": "object",
- "required": ["href"],
- "properties": {
- "href": {
- "description": "URI of the referenced resource.\n",
- "type": "string",
- "format": "url"
- }
- }
- },
- "object": {
- "description": "Link to a resource representing the VNF instance for which performance information is collected. Shall be present if the VNF instance information is accessible as a resource.\n"
- }
- }
- }
- }
- }
- },
- "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. 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.\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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- }
- }
- },
- "get": {
- "description": "Query Threshold\n\nThe client can use this method to query information about thresholds.\n",
- "parameters": [{
- "name": "Accept",
- "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n",
- "in": "header",
- "required": true,
- "type": "string"
- }, {
- "name": "Authorization",
- "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
- "in": "header",
- "required": false,
- "type": "string"
- }],
- "responses": {
- "200": {
- "description": "OK\nInformation about zero or more thresholds was queried successfully. The response body shall contain representations of zero or more thresholds.\n",
- "headers": {
- "Location": {
- "description": "The resource URI of the created VNF instance",
- "type": "string",
- "format": "url"
- },
- "Content-Type": {
- "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n",
- "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": {
- "type": "array",
- "items": {
- "description": "This type represents a threshold.\n",
- "type": "object",
- "required": ["id", "objectInstanceId", "criteria", "_links"],
- "properties": {
- "id": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- },
- "objectInstanceId": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- },
- "criteria": {
- "description": "This type represents criteria that define a threshold.\n",
- "type": "object",
- "required": ["performanceMetric", "thresholdType"],
- "properties": {
- "performanceMetric": {
- "description": "Defines the performance metric associated with the threshold, as specified in ETSI GS NFV-IFA 027).\n",
- "type": "string"
- },
- "thresholdType": {
- "description": "Type of threshold. This attribute determines which other attributes are present in the data structure. Permitted values: * SIMPLE: Single-valued static threshold In the present document, simple thresholds are defined. The definition of additional threshold types is left for future specification.\n",
- "type": "string",
- "enum": ["SIMPLE"]
- },
- "simpleThresholdDetails": {
- "description": "Details of a simple threshold. Shall be present if thresholdType=\"SIMPLE\".\n",
- "type": "object",
- "required": ["thresholdValue", "hysteresis"],
- "properties": {
- "thresholdValue": {
- "description": "The threshold value. Shall be represented as a floating point number.\n",
- "type": "integer"
- },
- "hysteresis": {
- "description": "The hysteresis of the threshold. Shall be represented as a non-negative floating point number. A notification with crossing direction \"UP\" will be generated if the measured value reaches or exceeds \"thresholdValue\" + \"hysteresis\". A notification with crossing direction \"DOWN\" will be generated if the measured value reaches or undercuts \"thresholdValue\" - \"hysteresis\". The hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or reject the request).\n",
- "type": "integer"
- }
- }
- }
- }
- },
- "_links": {
- "description": "Links for this resource.\n",
- "type": "object",
- "required": ["self"],
- "properties": {
- "self": {
- "description": "This type represents a link to a resource.\n",
- "type": "object",
- "required": ["href"],
- "properties": {
- "href": {
- "description": "URI of the referenced resource.\n",
- "type": "string",
- "format": "url"
- }
- }
- },
- "object": {
- "description": "Link to a resource representing the VNF instance for which performance information is collected. Shall be present if the VNF instance information is accessible as a resource.\n"
- }
- }
- }
- }
- }
- }
- },
- "400": {
- "description": "Bad Request\nInvalid attribute-based filtering parameters or Invalid attribute selector. It fhe 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.\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"
- }
- },
- "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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- }
- }
- }
- },
- "/thresholds/{thresholdId}": {
- "parameters": [{
- "name": "thresholdId",
- "description": "Identifier of the threshold. This identifier can be retrieved from the resource referenced by the \"Location\" HTTP header in the response to a POST request creating a new threshold resource. It can also be retrieved from the \"id\" attribute in the payload body of that response.\n",
- "in": "path",
- "type": "string",
- "required": true
- }],
- "get": {
- "description": "Query Threshold\n\nThe client can use this method for reading an individual threshold.\n",
- "parameters": [{
- "name": "Accept",
- "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n",
- "in": "header",
- "required": true,
- "type": "string"
- }, {
- "name": "Authorization",
- "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
- "in": "header",
- "required": false,
- "type": "string"
- }],
- "responses": {
- "200": {
- "description": "OK\nInformation about an individual threshold was queried successfully. The response body shall contain a representation of the threshold.\n",
- "headers": {
- "Content-Type": {
- "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n",
- "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": "This type represents a threshold.\n",
- "type": "object",
- "required": ["id", "objectInstanceId", "criteria", "_links"],
- "properties": {
- "id": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- },
- "objectInstanceId": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- },
- "criteria": {
- "description": "This type represents criteria that define a threshold.\n",
- "type": "object",
- "required": ["performanceMetric", "thresholdType"],
- "properties": {
- "performanceMetric": {
- "description": "Defines the performance metric associated with the threshold, as specified in ETSI GS NFV-IFA 027).\n",
- "type": "string"
- },
- "thresholdType": {
- "description": "Type of threshold. This attribute determines which other attributes are present in the data structure. Permitted values: * SIMPLE: Single-valued static threshold In the present document, simple thresholds are defined. The definition of additional threshold types is left for future specification.\n",
- "type": "string",
- "enum": ["SIMPLE"]
- },
- "simpleThresholdDetails": {
- "description": "Details of a simple threshold. Shall be present if thresholdType=\"SIMPLE\".\n",
- "type": "object",
- "required": ["thresholdValue", "hysteresis"],
- "properties": {
- "thresholdValue": {
- "description": "The threshold value. Shall be represented as a floating point number.\n",
- "type": "integer"
- },
- "hysteresis": {
- "description": "The hysteresis of the threshold. Shall be represented as a non-negative floating point number. A notification with crossing direction \"UP\" will be generated if the measured value reaches or exceeds \"thresholdValue\" + \"hysteresis\". A notification with crossing direction \"DOWN\" will be generated if the measured value reaches or undercuts \"thresholdValue\" - \"hysteresis\". The hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or reject the request).\n",
- "type": "integer"
- }
- }
- }
- }
- },
- "_links": {
- "description": "Links for this resource.\n",
- "type": "object",
- "required": ["self"],
- "properties": {
- "self": {
- "description": "This type represents a link to a resource.\n",
- "type": "object",
- "required": ["href"],
- "properties": {
- "href": {
- "description": "URI of the referenced resource.\n",
- "type": "string",
- "format": "url"
- }
- }
- },
- "object": {
- "description": "Link to a resource representing the VNF instance for which performance information is collected. Shall be present if the VNF instance information is accessible as a resource.\n"
- }
- }
- }
- }
- }
- },
- "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. 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.\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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- }
- }
- },
- "delete": {
- "description": "Delete Threshold\n\nThis method allows to delete a threshold.\n",
- "parameters": [{
- "name": "Authorization",
- "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
- "in": "header",
- "required": false,
- "type": "string"
- }],
- "responses": {
- "204": {
- "description": "No Content\nThe threshold was deleted successfully. The response body shall be empty.\n",
- "headers": {
- "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
- }
- }
- },
- "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. 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.\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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- }
- }
- }
- },
- "/subscriptions": {
- "post": {
- "description": "Subscribe\n\nThe POST method creates a new subscription. Creation of two subscription resources with the same callbackURI and the same filter can result in performance degradation and will provide duplicates of notifications to the NFVO, and might make sense only in very rare use cases. Consequently, the VNFM may either allow creating a subscription resource if another subscription resource with the same filter and callbackUri already exists (in which case it shall return the “201 Created†response code), or may decide to not create a duplicate subscription resource (in which case it shall return a “303 See Other†response code referencing the existing subscription resource with the same filter and callbackUri).\n",
- "parameters": [{
- "name": "PmSubscriptionRequest",
- "description": "Details of the subscription to be created.\n",
- "in": "body",
- "required": true,
- "schema": {
- "description": "This type represents a subscription request.\n",
- "type": "object",
- "required": ["callbackUri"],
- "properties": {
- "filter": {
- "description": "This type represents a filter that can be used to subscribe for notifications related to performance management events.\n",
- "type": "object",
- "properties": {
- "vnfInstanceSubscriptionFilter": {
- "description": "This type represents subscription filter criteria to match VNF instances.\n",
- "type": "object",
- "properties": {
- "vnfdIds": {
- "description": "If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. The attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances that are based on certain VNFDs in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n",
- "type": "array",
- "items": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- }
- },
- "vnfProductsFromProviders": {
- "description": "If present, match VNF instances that belong to VNF products from certain providers. The attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances that are based on certain VNFDs in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n",
- "type": "array",
- "items": {
- "type": "object",
- "required": ["vnfProvider"],
- "properties": {
- "vnfProvider": {
- "description": "Name of the VNF provider to match.\n",
- "type": "string"
- },
- "vnfProducts": {
- "description": "If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n",
- "type": "array",
- "items": {
- "type": "object",
- "required": ["vnfProductName"],
- "properties": {
- "vnfProductName": {
- "description": "Name of the VNF product to match.\n",
- "type": "string"
- },
- "versions": {
- "description": "If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n",
- "type": "array",
- "items": {
- "type": "object",
- "required": ["vnfSoftwareVersion"],
- "properties": {
- "vnfSoftwareVersion": {
- "description": "A version.\n",
- "type": "string"
- },
- "vnfdVersions": {
- "description": "If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n",
- "type": "array",
- "items": {
- "description": "A version.\n",
- "type": "string"
- }
- }
- }
- }
- }
- }
- }
- }
- }
- }
- },
- "vnfInstanceIds": {
- "description": "If present, match VNF instances with an instance identifier listed in this attribute. The attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF Instances in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n",
- "type": "array",
- "items": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- }
- },
- "vnfInstanceNames": {
- "description": "If present, match VNF instances with a VNF Instance Name listed in this attribute. The attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF Instances in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n",
- "type": "array",
- "items": {
- "type": "string"
- }
- }
- }
- },
- "notificationTypes": {
- "description": "Match particular notification types. Permitted values: * ThresholdCrossedNotification * PerformanceInformationAvailableNotification The permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the notification types to facilitate automated code generation systems.\n",
- "type": "string",
- "enum": ["ThresholdCrossedNotification", "PerformanceInformationAvailableNotification"]
- }
- }
- },
- "callbackUri": {
- "description": "The URI of the endpoint to send the notification to.\n",
- "type": "string",
- "format": "url"
- },
- "authentication": {
- "type": "object",
- "required": ["authType"],
- "properties": {
- "authType": {
- "description": "Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values: * BASIC: In every HTTP request to the notification endpoint, use HTTP Basic authentication with the client credentials. \n* OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use an OAuth 2.0 Bearer token, obtained\n using the client credentials grant type.\n* TLS_CERT: Every HTTP request to the notification endpoint is sent over a mutually authenticated TLS session, i.e. not only the\n server is authenticated, but also the client is authenticated\n during the TLS tunnel setup.\n",
- "type": "array",
- "items": {
- "type": "string",
- "enum": ["BASIC", "OAUTH2_CLIENT_CREDENTIALS", "TLS_CERT"]
- }
- },
- "paramsBasic": {
- "description": "Parameters for authentication/authorization using BASIC. Shall be present if authType is \"BASIC\" and the contained information has not been provisioned out of band. Shall be absent otherwise.\n",
- "type": "object",
- "properties": {
- "userName": {
- "description": "Username to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n",
- "type": "string"
- },
- "password": {
- "description": "Password to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n",
- "type": "string"
- }
- }
- },
- "paramsOauth2ClientCredentials": {
- "description": "Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS. Shall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band. Shall be absent otherwise.\n",
- "type": "object",
- "properties": {
- "clientId": {
- "description": "Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between subscriptions. The value of clientPassword should be generated by a random process.\n",
- "type": "string"
- },
- "clientPassword": {
- "description": "Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between subscriptions. The value of clientPassword should be generated by a random process.\n",
- "type": "string"
- },
- "tokenEndpoint": {
- "description": "String formatted according to IETF RFC 3986.\n",
- "type": "string"
- }
- }
- }
- }
- }
- }
- }
- }, {
- "name": "Accept",
- "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n",
- "in": "header",
- "required": true,
- "type": "string"
- }, {
- "name": "Authorization",
- "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
- "in": "header",
- "required": false,
- "type": "string"
- }, {
- "name": "Content-Type",
- "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n",
- "in": "header",
- "required": true,
- "type": "string"
- }],
- "responses": {
- "201": {
- "description": "Created\nThe subscription was created successfully. A representation of the created subscription resource shall be returned in the response body. The HTTP response shall include a \"Location\" HTTP header that contains the resource URI of the created subscription resource.\n",
- "headers": {
- "Location": {
- "description": "The resource URI of the created VNF instance",
- "type": "string",
- "format": "url"
- },
- "Content-Type": {
- "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n",
- "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": "This type represents a subscription.\n",
- "type": "object",
- "required": ["id", "callbackUri", "_links"],
- "properties": {
- "id": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- },
- "filter": {
- "description": "This type represents a filter that can be used to subscribe for notifications related to performance management events.\n",
- "type": "object",
- "properties": {
- "vnfInstanceSubscriptionFilter": {
- "description": "This type represents subscription filter criteria to match VNF instances.\n",
- "type": "object",
- "properties": {
- "vnfdIds": {
- "description": "If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. The attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances that are based on certain VNFDs in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n",
- "type": "array",
- "items": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- }
- },
- "vnfProductsFromProviders": {
- "description": "If present, match VNF instances that belong to VNF products from certain providers. The attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances that are based on certain VNFDs in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n",
- "type": "array",
- "items": {
- "type": "object",
- "required": ["vnfProvider"],
- "properties": {
- "vnfProvider": {
- "description": "Name of the VNF provider to match.\n",
- "type": "string"
- },
- "vnfProducts": {
- "description": "If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n",
- "type": "array",
- "items": {
- "type": "object",
- "required": ["vnfProductName"],
- "properties": {
- "vnfProductName": {
- "description": "Name of the VNF product to match.\n",
- "type": "string"
- },
- "versions": {
- "description": "If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n",
- "type": "array",
- "items": {
- "type": "object",
- "required": ["vnfSoftwareVersion"],
- "properties": {
- "vnfSoftwareVersion": {
- "description": "A version.\n",
- "type": "string"
- },
- "vnfdVersions": {
- "description": "If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n",
- "type": "array",
- "items": {
- "description": "A version.\n",
- "type": "string"
- }
- }
- }
- }
- }
- }
- }
- }
- }
- }
- },
- "vnfInstanceIds": {
- "description": "If present, match VNF instances with an instance identifier listed in this attribute. The attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF Instances in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n",
- "type": "array",
- "items": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- }
- },
- "vnfInstanceNames": {
- "description": "If present, match VNF instances with a VNF Instance Name listed in this attribute. The attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF Instances in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n",
- "type": "array",
- "items": {
- "type": "string"
- }
- }
- }
- },
- "notificationTypes": {
- "description": "Match particular notification types. Permitted values: * ThresholdCrossedNotification * PerformanceInformationAvailableNotification The permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the notification types to facilitate automated code generation systems.\n",
- "type": "string",
- "enum": ["ThresholdCrossedNotification", "PerformanceInformationAvailableNotification"]
- }
- }
- },
- "callbackUri": {
- "description": "The URI of the endpoint to send the notification to.\n",
- "type": "string",
- "format": "url"
- },
- "_links": {
- "description": "Links to resources related to this resource.\n",
- "type": "object",
- "required": ["self"],
- "properties": {
- "self": {
- "description": "This type represents a link to a resource.\n",
- "type": "object",
- "required": ["href"],
- "properties": {
- "href": {
- "description": "URI of the referenced resource.\n",
- "type": "string",
- "format": "url"
- }
- }
- }
- }
- }
- }
- }
- },
- "303": {
- "description": "See Other\nA subscription with the same callbackURI and the same filter already exists and the policy of the VNFM is to not create redundant subscriptions. The HTTP response shall include a \"Location\" HTTP header that contains the resource URI of the existing subscription resource. The response body shall be empty.\n"
- },
- "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. 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.\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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- }
- }
- },
- "get": {
- "description": "Query Subscription Information\n\nThe client can use this method to query the list of active subscriptions to Performance management notifications subscribed by the client.\n",
- "parameters": [{
- "name": "Accept",
- "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n",
- "in": "header",
- "required": true,
- "type": "string"
- }, {
- "name": "Authorization",
- "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
- "in": "header",
- "required": false,
- "type": "string"
- }],
- "responses": {
- "200": {
- "description": "OK\nThe list of subscriptions was queried successfully. The response body shall contain the representations of all active subscriptions of the functional block that invokes the method.\n",
- "headers": {
- "Content-Type": {
- "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n",
- "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": {
- "type": "array",
- "items": {
- "description": "This type represents a subscription.\n",
- "type": "object",
- "required": ["id", "callbackUri", "_links"],
- "properties": {
- "id": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- },
- "filter": {
- "description": "This type represents a filter that can be used to subscribe for notifications related to performance management events.\n",
- "type": "object",
- "properties": {
- "vnfInstanceSubscriptionFilter": {
- "description": "This type represents subscription filter criteria to match VNF instances.\n",
- "type": "object",
- "properties": {
- "vnfdIds": {
- "description": "If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. The attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances that are based on certain VNFDs in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n",
- "type": "array",
- "items": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- }
- },
- "vnfProductsFromProviders": {
- "description": "If present, match VNF instances that belong to VNF products from certain providers. The attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances that are based on certain VNFDs in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n",
- "type": "array",
- "items": {
- "type": "object",
- "required": ["vnfProvider"],
- "properties": {
- "vnfProvider": {
- "description": "Name of the VNF provider to match.\n",
- "type": "string"
- },
- "vnfProducts": {
- "description": "If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n",
- "type": "array",
- "items": {
- "type": "object",
- "required": ["vnfProductName"],
- "properties": {
- "vnfProductName": {
- "description": "Name of the VNF product to match.\n",
- "type": "string"
- },
- "versions": {
- "description": "If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n",
- "type": "array",
- "items": {
- "type": "object",
- "required": ["vnfSoftwareVersion"],
- "properties": {
- "vnfSoftwareVersion": {
- "description": "A version.\n",
- "type": "string"
- },
- "vnfdVersions": {
- "description": "If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n",
- "type": "array",
- "items": {
- "description": "A version.\n",
- "type": "string"
- }
- }
- }
- }
- }
- }
- }
- }
- }
- }
- },
- "vnfInstanceIds": {
- "description": "If present, match VNF instances with an instance identifier listed in this attribute. The attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF Instances in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n",
- "type": "array",
- "items": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- }
- },
- "vnfInstanceNames": {
- "description": "If present, match VNF instances with a VNF Instance Name listed in this attribute. The attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF Instances in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n",
- "type": "array",
- "items": {
- "type": "string"
- }
- }
- }
- },
- "notificationTypes": {
- "description": "Match particular notification types. Permitted values: * ThresholdCrossedNotification * PerformanceInformationAvailableNotification The permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the notification types to facilitate automated code generation systems.\n",
- "type": "string",
- "enum": ["ThresholdCrossedNotification", "PerformanceInformationAvailableNotification"]
- }
- }
- },
- "callbackUri": {
- "description": "The URI of the endpoint to send the notification to.\n",
- "type": "string",
- "format": "url"
- },
- "_links": {
- "description": "Links to resources related to this resource.\n",
- "type": "object",
- "required": ["self"],
- "properties": {
- "self": {
- "description": "This type represents a link to a resource.\n",
- "type": "object",
- "required": ["href"],
- "properties": {
- "href": {
- "description": "URI of the referenced resource.\n",
- "type": "string",
- "format": "url"
- }
- }
- }
- }
- }
- }
- }
- }
- },
- "400": {
- "description": "Bad Request\nInvalid attribute-based filtering parameters or Invalid attribute selector. It fhe 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.\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"
- }
- },
- "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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- }
- }
- }
- },
- "/subscriptions/{subscriptionId}": {
- "parameters": [{
- "name": "subscriptionId",
- "description": "This identifier can be retrieved from the resource referenced by the \"Location\" HTTP header in the response to a POST request creating a new subscription resource. It can also be retrieved from the \"id\" attribute in the payload body of that response.\n",
- "in": "path",
- "type": "string",
- "required": true
- }],
- "get": {
- "description": "Query Subscription Information\n\nThe client can use this method for reading an individual subscription about Performance management notifications subscribed by the client.\n",
- "parameters": [{
- "name": "Accept",
- "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n",
- "in": "header",
- "required": true,
- "type": "string"
- }, {
- "name": "Authorization",
- "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
- "in": "header",
- "required": false,
- "type": "string"
- }],
- "responses": {
- "200": {
- "description": "OK\nThe subscription was read successfully. The response body shall contain a representation of the subscription resource.\n",
- "headers": {
- "Content-Type": {
- "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n",
- "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": "This type represents a subscription.\n",
- "type": "object",
- "required": ["id", "callbackUri", "_links"],
- "properties": {
- "id": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- },
- "filter": {
- "description": "This type represents a filter that can be used to subscribe for notifications related to performance management events.\n",
- "type": "object",
- "properties": {
- "vnfInstanceSubscriptionFilter": {
- "description": "This type represents subscription filter criteria to match VNF instances.\n",
- "type": "object",
- "properties": {
- "vnfdIds": {
- "description": "If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. The attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances that are based on certain VNFDs in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n",
- "type": "array",
- "items": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- }
- },
- "vnfProductsFromProviders": {
- "description": "If present, match VNF instances that belong to VNF products from certain providers. The attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances that are based on certain VNFDs in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n",
- "type": "array",
- "items": {
- "type": "object",
- "required": ["vnfProvider"],
- "properties": {
- "vnfProvider": {
- "description": "Name of the VNF provider to match.\n",
- "type": "string"
- },
- "vnfProducts": {
- "description": "If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n",
- "type": "array",
- "items": {
- "type": "object",
- "required": ["vnfProductName"],
- "properties": {
- "vnfProductName": {
- "description": "Name of the VNF product to match.\n",
- "type": "string"
- },
- "versions": {
- "description": "If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n",
- "type": "array",
- "items": {
- "type": "object",
- "required": ["vnfSoftwareVersion"],
- "properties": {
- "vnfSoftwareVersion": {
- "description": "A version.\n",
- "type": "string"
- },
- "vnfdVersions": {
- "description": "If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n",
- "type": "array",
- "items": {
- "description": "A version.\n",
- "type": "string"
- }
- }
- }
- }
- }
- }
- }
- }
- }
- }
- },
- "vnfInstanceIds": {
- "description": "If present, match VNF instances with an instance identifier listed in this attribute. The attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF Instances in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n",
- "type": "array",
- "items": {
- "description": "An identifier with the intention of being globally unique.\n",
- "type": "string"
- }
- },
- "vnfInstanceNames": {
- "description": "If present, match VNF instances with a VNF Instance Name listed in this attribute. The attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF Instances in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n",
- "type": "array",
- "items": {
- "type": "string"
- }
- }
- }
- },
- "notificationTypes": {
- "description": "Match particular notification types. Permitted values: * ThresholdCrossedNotification * PerformanceInformationAvailableNotification The permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the notification types to facilitate automated code generation systems.\n",
- "type": "string",
- "enum": ["ThresholdCrossedNotification", "PerformanceInformationAvailableNotification"]
- }
- }
- },
- "callbackUri": {
- "description": "The URI of the endpoint to send the notification to.\n",
- "type": "string",
- "format": "url"
- },
- "_links": {
- "description": "Links to resources related to this resource.\n",
- "type": "object",
- "required": ["self"],
- "properties": {
- "self": {
- "description": "This type represents a link to a resource.\n",
- "type": "object",
- "required": ["href"],
- "properties": {
- "href": {
- "description": "URI of the referenced resource.\n",
- "type": "string",
- "format": "url"
- }
- }
- }
- }
- }
- }
- }
- },
- "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. 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.\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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- }
- }
- },
- "delete": {
- "description": "Terminate Subscription\n\nThis method terminates an individual subscription.\n",
- "parameters": [{
- "name": "Authorization",
- "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
- "in": "header",
- "required": false,
- "type": "string"
- }],
- "responses": {
- "204": {
- "description": "No Content\nThe subscription resource was deleted successfully. The response body shall be empty.\n",
- "headers": {
- "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
- }
- }
- },
- "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. 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.\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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- },
- "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"
- }
- }
- }
- }
- }
- }
- }
- }
-}
\ No newline at end of file
diff --git a/SOL003/VNFPerformanceManagementNotification-API/environment/variables.txt b/SOL003/VNFPerformanceManagementNotification-API/environment/variables.txt
deleted file mode 100644
index bd4361c1..00000000
--- a/SOL003/VNFPerformanceManagementNotification-API/environment/variables.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-*** Variables ***
-${callback_port} 9091
-${callback_uri} http://localhost:${callback_port}
-${callback_endpoint} /vnfpm/subscriptios
-${callback_endpoint_error} /subs_404
-${total_polling_time} 2 min
-${polling_interval} 10 sec
-${MOCK_SERVER_JAR} ../../../bin/mockserver-netty-5.5.0-jar-with-dependencies.jar
\ No newline at end of file
diff --git a/SOL003/VNFPerformanceManagementNotification-API/schemas/ProblemDetails.schema.json b/SOL003/VNFPerformanceManagementNotification-API/schemas/ProblemDetails.schema.json
deleted file mode 100644
index 2af3ef9b..00000000
--- a/SOL003/VNFPerformanceManagementNotification-API/schemas/ProblemDetails.schema.json
+++ /dev/null
@@ -1 +0,0 @@
-{ "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" } }}
\ No newline at end of file
diff --git a/SOL005/NSDManagement-API/NSDManagementKeywords.robot b/SOL005/NSDManagement-API/NSDManagementKeywords.robot
new file mode 100644
index 00000000..533b91a8
--- /dev/null
+++ b/SOL005/NSDManagement-API/NSDManagementKeywords.robot
@@ -0,0 +1,184 @@
+*** Settings ***
+Resource environment/variables.txt
+Resource environment/subscriptions.txt
+Library REST ${NFVO_SCHEMA}://${NFVO_HOST}:${NFVO_PORT} ssl_verify=false
+Library MockServerLibrary
+Library OperatingSystem
+Library BuiltIn
+Library JSONLibrary
+Library Collections
+Library JSONSchemaLibrary schemas/
+Library Process
+
+*** Keywords ***
+Get all NS Descriptor Subscriptions
+ [Documentation] This method shall support the URI query parameters, request and response data structures, and response codes, as
+ ... specified in the Tables 5.4.8.3.2-1 and 5.4.8.3.2-2.
+ Log Trying to get the list of subscriptions
+ Set Headers {"Accept": "${ACCEPT_JSON}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions
+ ${output}= Output response
+ Set Suite Variable ${response} ${output}
+
+
+Get NS Descriptor Subscriptions with attribute-based filters
+ Log Trying to get the list of subscriptions using filters
+ Set Headers {"Accept": "${ACCEPT_JSON}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions?${filter_ok}
+ ${output}= Output response
+ Set Suite Variable ${response} ${output}
+
+
+Get NS Descriptor Subscriptions with invalid attribute-based filters
+ Log Trying to get the list of subscriptions using filters with wrong attribute name
+ Set Headers {"Accept": "${ACCEPT_JSON}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions?${filter_ko}
+ ${output}= Output response
+ Set Suite Variable ${response} ${output}
+
+
+Get NS Descriptor Subscriptions with invalid resource endpoint
+ Log Trying to perform a request on a Uri which doesn't exist
+ Set Headers {"Accept": "${ACCEPT_JSON}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ GET ${apiRoot}/${apiName}/${apiVersion}/subscription
+ ${output}= Output response
+ Set Suite Variable ${response} ${output}
+
+
+Send Post Request for NS Descriptor Subscription
+ [Documentation] This method shall support the URI query parameters, request and response data structures, and response codes, as
+ ... specified in the Tables 5.4.8.3.1-1 and 5.4.8.3.1-2.
+ Log Trying to create a new subscription
+ Set Headers {"Accept": "${ACCEPT_JSON}"}
+ Set Headers {"Content-Type": "${CONTENT_TYPE_JSON}"}
+ ${body}= Get File jsons/subscriptions.json
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ POST ${apiRoot}/${apiName}/${apiVersion}/subscriptions ${body}
+ ${output}= Output response
+ Set Suite Variable ${response} ${output}
+ Run Keyword If ${NFVO_CHECKS_NOTIF_ENDPOINT} == 1
+ ... Check Notification Endpoint
+
+
+Send Post Request for Duplicated NS Descriptor Subscription
+ Log Trying to create a subscription with an already created content
+ Set Headers {"Accept": "${ACCEPT_JSON}"}
+ Set Headers {"Content-Type": "${CONTENT_TYPE_JSON}"}
+ ${body}= Get File jsons/subscriptions.json
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ POST ${apiRoot}/${apiName}/${apiVersion}/subscriptions ${body}
+ ${output}= Output response
+ Set Suite Variable ${response} ${output}
+ Run Keyword If ${NFVO_CHECKS_NOTIF_ENDPOINT} == 1
+ ... Check Notification Endpoint
+
+
+
+Send Put Request for NS Descriptor Subscriptions
+ Pass Execution If ${testOptionalMethods} == 0 optional methods are not implemented on the FUT. Skipping test.
+ Log Trying to perform a PUT. This method should not be implemented
+ Set Headers {"Accept": "${ACCEPT_JSON}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ PUT ${apiRoot}/${apiName}/${apiVersion}/subscriptions
+ ${output}= Output response
+ Set Suite Variable ${response} ${output}
+
+
+Send Patch Request for NS Descriptor Subscriptions
+ Pass Execution If ${testOptionalMethods} == 0 optional methods are not implemented on the FUT. Skipping test.
+ Log Trying to perform a PATCH. This method should not be implemented
+ Set Headers {"Accept": "${ACCEPT_JSON}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ PATCH ${apiRoot}/${apiName}/${apiVersion}/subscriptions
+ ${output}= Output response
+ Set Suite Variable ${response} ${output}
+
+Send Delete Request for NS Descriptor Subscriptions
+ Pass Execution If ${testOptionalMethods} == 0 optional methods are not implemented on the FUT. Skipping test.
+ Log Trying to perform a DELETE. This method should not be implemented
+ Set Headers {"Accept": "${ACCEPT_JSON}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ DELETE ${apiRoot}/${apiName}/${apiVersion}/subscriptions
+ ${output}= Output response
+ Set Suite Variable ${response} ${output}
+
+
+Check HTTP Response Status Code Is
+ [Arguments] ${expected_status}
+ Should Be Equal ${response['status']} ${expected_status}
+ Log Status code validated
+
+
+
+Check HTTP Response Body Json Schema Is
+ [Arguments] ${input}
+ Should Contain ${response['headers']['Content-Type']} application/json
+ ${schema} = Catenate ${input} .schema.json
+ Validate Json ${schema} ${response['body']}
+ Log Json Schema Validation OK
+
+
+Check HTTP Response Body Is Empty
+ Should Be Empty ${response['body']}
+ Log No json schema is provided. Validation OK
+
+
+Check HTTP Response Body Subscriptions Match the requested Attribute-Based Filter
+ Log Check Response includes VNF Package Management according to filter
+ #TODO
+
+
+Check HTTP Response Body Matches the Subscription
+ Log Check Response matches subscription
+ ${body}= Get File jsons/subscriptions.json
+ ${subscription}= evaluate json.loads('''${body}''') json
+ Should Be Equal ${response['body']['callbackUri']} ${subscription['callbackUri']}
+
+
+Check Postcondition NS Descriptor Subscription Is Set
+ Log Check Postcondition subscription exist
+ Log Trying to get the subscription
+ Set Headers {"Accept": "${ACCEPT_JSON}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${response['body']['id']}
+ ${output}= Output response
+ Set Suite Variable ${response} ${output}
+ Check HTTP Response Status Code Is 200
+
+
+Check Postcondition Subscription Resource URI Returned in Location Header Is Valid
+ Log Going to check postcondition
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ GET ${response.headers['Location']}
+ Integer response status 200
+ Log Received a 200 OK as expected
+ ${contentType}= Output response headers Content-Type
+ Should Contain ${contentType} application/json
+ ${result}= Output response body
+ Validate Json NsdmSubscription.schema.json ${result}
+ Log Validated NsdmSubscription schema
+
+
+Check HTTP Response Header Contains
+ [Arguments] ${CONTENT_TYPE}
+ Should Contain ${response.headers} ${CONTENT_TYPE}
+ Log Header is present
+
+
+Create Sessions
+ Pass Execution If ${NFVO_CHECKS_NOTIF_ENDPOINT} == 0 MockServer not started as NFVO is not checking the notification endpoint
+ Start Process java -jar ${MOCK_SERVER_JAR} -serverPort ${callback_port} alias=mockInstance
+ Wait For Process handle=mockInstance timeout=5s on_timeout=continue
+ Create Mock Session ${callback_uri}
+
+
+Check Notification Endpoint
+ &{notification_request}= Create Mock Request Matcher GET ${callback_endpoint}
+ &{notification_response}= Create Mock Response headers="Content-Type: application/json" status_code=204
+ Create Mock Expectation ${notification_request} ${notification_response}
+ Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${notification_request}
+ Clear Requests ${callback_endpoint}
diff --git a/SOL005/NSDManagement-API/NSDManagementNotification.robot b/SOL005/NSDManagement-API/NSDManagementNotification.robot
index 4af02007..b978a187 100644
--- a/SOL005/NSDManagement-API/NSDManagementNotification.robot
+++ b/SOL005/NSDManagement-API/NSDManagementNotification.robot
@@ -15,7 +15,7 @@ Check Notification Endpoint
&{req}= Create Mock Request Matcher GET ${callback_endpoint}
&{rsp}= Create Mock Response headers="Content-Type: application/json" status_code=204
Create Mock Expectation ${req} ${rsp}
- Sleep ${sleep_interval}
+ Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
Verify Mock Expectation ${req}
Clear Requests ${callback_endpoint}
@@ -26,7 +26,7 @@ Post NSD Change Notification
&{req}= Create Mock Request Matcher POST ${callback_endpoint} 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}
+ Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
Log Verifying results
Verify Mock Expectation ${req}
Log Cleaning the endpoint
@@ -39,7 +39,7 @@ Post NSD Deletion Notification
&{req}= Create Mock Request Matcher POST ${callback_endpoint} 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}
+ Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
Log Verifying results
Verify Mock Expectation ${req}
Log Cleaning the endpoint
@@ -53,7 +53,7 @@ Post NSD Onboard Failure Notification
&{req}= Create Mock Request Matcher POST ${callback_endpoint} 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}
+ Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
Log Verifying results
Verify Mock Expectation ${req}
Log Cleaning the endpoint
@@ -66,7 +66,7 @@ Post NSD Onboard Notification
&{req}= Create Mock Request Matcher POST ${callback_endpoint} 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}
+ Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
Log Verifying results
Verify Mock Expectation ${req}
Log Cleaning the endpoint
@@ -80,7 +80,7 @@ Post PNFD Deletion Notification
&{req}= Create Mock Request Matcher POST ${callback_endpoint} 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}
+ Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
Log Verifying results
Verify Mock Expectation ${req}
Log Cleaning the endpoint
@@ -94,7 +94,7 @@ Post PNFD Onboard Failure Notification
&{req}= Create Mock Request Matcher POST ${callback_endpoint} 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}
+ Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
Log Verifying results
Verify Mock Expectation ${req}
Log Cleaning the endpoint
@@ -107,7 +107,7 @@ Post PNFD Onboard Notification
&{req}= Create Mock Request Matcher POST ${callback_endpoint} 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}
+ Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
Log Verifying results
Verify Mock Expectation ${req}
Log Cleaning the endpoint
@@ -121,7 +121,7 @@ Post Notification Negative 404
&{req}= Create Mock Request Matcher POST ${callback_endpoint_error} body_type="JSON_SCHEMA" body=${BODY}
&{rsp}= Create Mock Response headers="Content-Type: application/json" status_code=404
Create Mock Expectation ${req} ${rsp}
- Sleep ${sleep_interval}
+ Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
Log Verifying results
Verify Mock Expectation ${req}
Log Cleaning the endpoint
@@ -134,7 +134,7 @@ PUT VNF Package Management Notification
&{req}= Create Mock Request Matcher PUT ${callback_endpoint}
&{rsp}= Create Mock Response status_code=405
Create Mock Expectation ${req} ${rsp}
- Sleep ${sleep_interval}
+ Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
Log Verifying results
Verify Mock Expectation ${req}
Log Cleaning the endpoint
@@ -147,7 +147,7 @@ PATCH VNF Package Management Notification
&{req}= Create Mock Request Matcher PATCH ${callback_endpoint}
&{rsp}= Create Mock Response status_code=405
Create Mock Expectation ${req} ${rsp}
- Sleep ${sleep_interval}
+ Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
Log Verifying results
Verify Mock Expectation ${req}
Log Cleaning the endpoint
@@ -160,7 +160,7 @@ DELETE VNF Package Management Notification
&{req}= Create Mock Request Matcher DELETE ${callback_endpoint}
&{rsp}= Create Mock Response status_code=405
Create Mock Expectation ${req} ${rsp}
- Sleep ${sleep_interval}
+ Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${req}
Log Verifying results
Verify Mock Expectation ${req}
Log Cleaning the endpoint
diff --git a/SOL005/NSDManagement-API/Subscriptions.robot b/SOL005/NSDManagement-API/Subscriptions.robot
index 071f16ff..505de9cd 100644
--- a/SOL005/NSDManagement-API/Subscriptions.robot
+++ b/SOL005/NSDManagement-API/Subscriptions.robot
@@ -2,139 +2,73 @@
Library JSONSchemaLibrary schemas/
Resource environment/variables.txt # Generic Parameters
Resource environment/subscriptions.txt
+Resource NSDManagementKeywords.robot
Library OperatingSystem
Library JSONLibrary
-Library REST ${NFVO_SCHEMA}://${NFVO_HOST}:${NFVO_PORT}
+Library Process
+Library REST ${NFVO_SCHEMA}://${NFVO_HOST}:${NFVO_PORT} ssl_verify=false
+Suite Setup Create Sessions
+Suite Teardown Terminate All Processes kill=true
*** Test Cases ***
-GET Subscription
- [Documentation] This method shall support the URI query parameters, request and response data structures, and response codes, as
- ... specified in the Tables 5.4.8.3.2-1 and 5.4.8.3.2-2.
- Log Trying to get the list of subscriptions
- Set Headers {"Accept": "${ACCEPT_JSON}"}
- Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
- GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions
- Integer response status 200
- Log Received a 200 OK as expected
- ${contentType}= Output response headers Content-Type
- Should Contain ${contentType} ${CONTENT_TYPE_JSON}
- ${result}= Output response body
- Validate Json NsdmSubscriptions.schema.json ${result}
- Log Validated NsdmSubscription schema
+Get All NS Descriptor Subscriptions
+ Get all NS Descriptor Subscriptions
+ Check HTTP Response Status Code Is 200
+ Check HTTP Response Body Json Schema Is NsdmSubscriptions
+
-GET Subscription - Filter
- Log Trying to get the list of subscriptions using filters
- Set Headers {"Accept": "${ACCEPT_JSON}"}
- Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
- GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions?${filter_ok}
- Integer response status 200
- Log Received a 200 OK as expected
- ${contentType}= Output response headers Content-Type
- Should Contain ${contentType} ${CONTENT_TYPE_JSON}
- ${result}= Output response body
- Validate Json NsdmSubscriptions.schema.json ${result}
- Log Validated NsdmSubscription schema
+Get NS Descriptor Subscriptions with attribute-based filter
+ Get NS Descriptor Subscriptions with attribute-based filters
+ Check HTTP Response Status Code Is 200
+ Check HTTP Response Body Json Schema Is NsdmSubscription
+ Check HTTP Response Body Subscriptions Match the requested Attribute-Based Filter
+
-GET Subscription - Negative Filter
- Log Trying to get the list of subscriptions using filters with wrong attribute name
- Set Headers {"Accept": "${ACCEPT_JSON}"}
- Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
- GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions?${filter_ok}
- Integer response status 400
- Log Received a 400 Bad Request as expected
- ${contentType}= Output response headers Content-Type
- Should Contain ${contentType} ${CONTENT_TYPE_JSON}
- Log Trying to validate ProblemDetails
- ${problemDetails}= Output response body
- Validate Json ProblemDetails.schema.json ${problemDetails}
- Log Validation OK
+Get NS Descriptor Subscriptions with invalid attribute-based filter
+ Get NS Descriptor Subscriptions with invalid attribute-based filters
+ Check HTTP Response Status Code Is 400
+ Check HTTP Response Body Json Schema Is ProblemDetails
-GET Subscription - Negative (Not Found)
- Log Trying to perform a request on a Uri which doesn't exist
- Set Headers {"Accept": "${ACCEPT_JSON}"}
- Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
- GET ${apiRoot}/${apiName}/${apiVersion}/subscription
- Integer response status 404
- Log Received 404 Not Found as expected
- ${contentType}= Output response headers Content-Type
- Should Contain ${contentType} ${CONTENT_TYPE_JSON}
- Log Trying to validate ProblemDetails
- ${problemDetails}= Output response body
- Validate Json ProblemDetails.schema.json ${problemDetails}
- Log Validation OK
-POST Subscription
- [Documentation] This method shall support the URI query parameters, request and response data structures, and response codes, as
- ... specified in the Tables 5.4.8.3.1-1 and 5.4.8.3.1-2.
- Log Trying to create a new subscription
- Set Headers {"Accept": "${ACCEPT_JSON}"}
- Set Headers {"Content-Type": "${CONTENT_TYPE_JSON}"}
- ${body}= Get File jsons/subscriptions.json
- Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
- POST ${apiRoot}/${apiName}/${apiVersion}/subscriptions ${body}
- Integer response status 201
- Log Received 201 Created as expected
- ${headers}= Output response headers
- Should Contain ${headers} Location
- Log Response has header Location
- ${result}= Output response body
- Validate Json NsdmSubscription.schema.json ${result}
- Log Validation of NsdmSubscription OK
+GET NS Descriptor Subscription with invalid resource endpoint
+ Get NS Descriptor Subscriptions with invalid resource endpoint
+ Check HTTP Response Status Code Is 404
+
+
+Create new NS Descriptor subscription
+ Send Post Request for NS Descriptor Subscription
+ Check HTTP Response Status Code Is 201
+ Check HTTP Response Body Json Schema Is NsdmSubscription
+ Check HTTP Response Body Matches the Subscription
+ Check Postcondition NS Descriptor Subscription Is Set
+
-POST Subscription - DUPLICATION
- Log Trying to create a subscription with an already created content
- Pass Execution If ${NFVO_DUPLICATION} == 0 NFVO is not permitting duplication. Skipping the test
- Set Headers {"Accept": "${ACCEPT_JSON}"}
- Set Headers {"Content-Type": "${CONTENT_TYPE_JSON}"}
- ${body}= Get File jsons/subscriptions.json
- Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
- POST ${apiRoot}/${apiName}/${apiVersion}/subscriptions ${body}
- Integer response status 201
- Log Received 201 Created as expected
- ${headers}= Output response headers
- Should Contain ${headers} Location
- Log Response has header Location
- ${result}= Output response body
- Validate Json NsdmSubscription.schema.json ${result}
- Log Validation of NsdmSubscription OK
+Create duplicated NS Descriptor subscription with duplication handler
+ Send Post Request for Duplicated NS Descriptor Subscription
+ Check HTTP Response Status Code Is 303
+ Check HTTP Response Body Is Empty
+ Check HTTP Response Header Contains Location
+ Check Postcondition Subscription Resource URI Returned in Location Header Is Valid
-POST Subscription - NO DUPLICATION
- Log Trying to create a subscription with an already created content
- Pass Execution If ${NFVO_DUPLICATION} == 1 NFVO is permitting duplication. Skipping the test
- Set Headers {"Accept": "${ACCEPT_JSON}"}
- Set Headers {"Content-Type": "${CONTENT_TYPE_JSON}"}
- ${body}= Get File jsons/subscriptions.json
- Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
- POST ${apiRoot}/${apiName}/${apiVersion}/subscriptions ${body}
- Integer response status 303
- Log Received 303 See Other as expected
- ${headers}= Output response headers
- Should Contain ${headers} Location
- Log Response header contains Location
-PUT Subscription - (Method not implemented)
- Pass Execution If ${testOptionalMethods} == 0 optional methods are not implemented on the FUT. Skipping test.
- Log Trying to perform a PUT. This method should not be implemented
- Set Headers {"Accept": "${ACCEPT_JSON}"}
- Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
- PUT ${apiRoot}/${apiName}/${apiVersion}/subscriptions
- Integer response status 405
- Log Received 405 Method not implemented as expected
+Create duplicated NS Descriptor subscription without duplication handler
+ Send Post Request for Duplicated NS Descriptor Subscription
+ Check HTTP Response Status Code Is 201
+ Check HTTP Response Body Json Schema Is PmSubscription
+ Check HTTP Response Body Matches the Subscription
+ Check Postcondition NS Descriptor Subscription Is Set
-PATCH Subscription - (Method not implemented)
- Pass Execution If ${testOptionalMethods} == 0 optional methods are not implemented on the FUT. Skipping test.
- Log Trying to perform a PATCH. This method should not be implemented
- Set Headers {"Accept": "${ACCEPT_JSON}"}
- Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
- PATCH ${apiRoot}/${apiName}/${apiVersion}/subscriptions
- Integer response status 405
- Log Received 405 Method not implemented as expected
-DELETE Subscription - (Method not implemented)
- Pass Execution If ${testOptionalMethods} == 0 optional methods are not implemented on the FUT. Skipping test.
- Log Trying to perform a DELETE. This method should not be implemented
- Set Headers {"Accept": "${ACCEPT_JSON}"}
- Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
- DELETE ${apiRoot}/${apiName}/${apiVersion}/subscriptions
- Integer response status 405
- Log Received 405 Method not implemented as expected
+PUT NS Descriptor Subscriptions - Method not implemented
+ Send Put Request for NS Descriptor Subscriptions
+ Check HTTP Response Status Code Is 405
+
+
+PATCH NS Descriptor Subscriptions - Method not implemented
+ Send Patch Request for NS Descriptor Subscriptions
+ Check HTTP Response Status Code Is 405
+
+
+DELETE NS Descriptor Subscriptions - Method not implemented
+ Send Delete Request for NS Descriptor Subscriptions
+ Check HTTP Response Status Code Is 405
diff --git a/SOL005/NSDManagement-API/environment/subscriptions.txt b/SOL005/NSDManagement-API/environment/subscriptions.txt
index 63a33d5e..553e803c 100644
--- a/SOL005/NSDManagement-API/environment/subscriptions.txt
+++ b/SOL005/NSDManagement-API/environment/subscriptions.txt
@@ -1,4 +1,3 @@
*** Variables ***
-${filter_ok} callbackUri=http://127.0.0.1/subscription
+${filter_ok} callbackUri=http://172.22.1.7:9091/nsd/subscriptions
${filter_ko} nfvId=f9f130e4-05eb-4082-a676-4c97d13a883d # Not existant filter attribute-based
-${NFVO_DUPLICATION} 0
diff --git a/SOL005/NSDManagement-API/environment/variables.txt b/SOL005/NSDManagement-API/environment/variables.txt
index e588bf2a..d55b443e 100644
--- a/SOL005/NSDManagement-API/environment/variables.txt
+++ b/SOL005/NSDManagement-API/environment/variables.txt
@@ -16,10 +16,16 @@ ${NFVO_AUTH_USAGE} 1
${MOCK_SERVER_JAR} ../../../bin/mockserver-netty-5.5.0-jar-with-dependencies.jar
-${callback_uri} http://localhost
${callback_port} 9091
-${callback_endpoint} /endpoint
-${callback_endpoint_error} /endpoint_404
-${sleep_interval} 20s
+${callback_uri} http://172.22.1.7:${callback_port}
+${callback_endpoint} /nsd/subscriptions
+${callback_endpoint_error} /subs_404
${testOptionalMethods} 0
+
+${NFVO_CHECKS_NOTIF_ENDPOINT} 1 ## If true, during subscription, the FUT performs a get to the notification endpoint
+
+${NFVO_ALLOWS_DUPLICATE_SUBS} 1
+${total_polling_time} 2 min
+${polling_interval} 10 sec
+${response}
\ No newline at end of file
diff --git a/SOL005/NSDManagement-API/jsons/subscriptions.json b/SOL005/NSDManagement-API/jsons/subscriptions.json
index ccf9f514..c77b5199 100644
--- a/SOL005/NSDManagement-API/jsons/subscriptions.json
+++ b/SOL005/NSDManagement-API/jsons/subscriptions.json
@@ -1,3 +1,3 @@
{
- "callbackUri": "http://127.0.0.1/subscribe"
+ "callbackUri": "http://172.22.1.7:9091/nsd/subscriptions"
}
\ No newline at end of file
diff --git a/SOL005/NSPerformanceManagement-API/NSPerformanceManagementKeywords.robot b/SOL005/NSPerformanceManagement-API/NSPerformanceManagementKeywords.robot
new file mode 100644
index 00000000..7e103f5b
--- /dev/null
+++ b/SOL005/NSPerformanceManagement-API/NSPerformanceManagementKeywords.robot
@@ -0,0 +1,210 @@
+*** Settings ***
+Resource environment/variables.txt
+Resource environment/subscriptions.txt
+Library REST ${NFVO_SCHEMA}://${NFVO_HOST}:${NFVO_PORT} ssl_verify=false
+Library MockServerLibrary
+Library OperatingSystem
+Library BuiltIn
+Library JSONLibrary
+Library Collections
+Library JSONSchemaLibrary schemas/
+Library Process
+
+*** Keywords ***
+Get all NSD Performance Subscriptions
+ [Documentation] The client can use this method to query the list of active subscriptions to Performance management notifications
+ ... subscribed by the client.
+ ... This method shall follow the provisions specified in the Tables 7.4.7.3.2-1 and 7.4.7.3.2-2 for URI query parameters,
+ ... request and response data structures, and response codes.
+ Set headers {"Accept": "${ACCEPT_JSON}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions
+ ${output}= Output response
+ Set Suite Variable ${response} ${output}
+
+
+Get NSD Performance Subscriptions with attribute-based filters
+ [Documentation] The client can use this method to query the list of active subscriptions to Performance management notifications
+ ... subscribed by the client.
+ ... This method shall follow the provisions specified in the Tables 7.4.7.3.2-1 and 7.4.7.3.2-2 for URI query parameters,
+ ... request and response data structures, and response codes.
+ Set headers {"Accept": "${ACCEPT_JSON}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions?${filter_ok}
+ ${output}= Output response
+ Set Suite Variable ${response} ${output}
+
+
+Get NSD Performance Subscriptions with invalid attribute-based filters
+ [Documentation] The client can use this method to query the list of active subscriptions to Performance management notifications
+ ... subscribed by the client.
+ ... This method shall follow the provisions specified in the Tables 7.4.7.3.2-1 and 7.4.7.3.2-2 for URI query parameters,
+ ... request and response data structures, and response codes.
+ Set headers {"Accept": "${ACCEPT_JSON}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions?${filter_ko}
+ ${output}= Output response
+ Set Suite Variable ${response} ${output}
+
+
+Get NSD Performance Subscriptions with invalid resource endpoint
+ [Documentation] The client can use this method to query the list of active subscriptions to Performance management notifications
+ ... subscribed by the client.
+ ... This method shall follow the provisions specified in the Tables 7.4.7.3.2-1 and 7.4.7.3.2-2 for URI query parameters,
+ ... request and response data structures, and response codes.
+ Set headers {"Accept": "${ACCEPT_JSON}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ GET ${apiRoot}/${apiName}/${apiVersion}/subscription
+ ${output}= Output response
+ Set Suite Variable ${response} ${output}
+
+
+Send Post Request for NSD Performance Subscription
+ [Documentation] The POST method creates a new subscription
+ ... This method shall follow the provisions specified in the Tables 7.4.7.3.1-1 and 7.4.7.3.1-2 for URI query parameters,
+ ... request and response data structures, and response codes.
+ ... Creation of two subscription resources with the same callbackURI and the same filter can result in performance
+ ... degradation and will provide duplicates of notifications to the OSS, and might make sense only in very rare use cases.
+ ... Consequently, the NFVO may either allow creating a subscription resource if another subscription resource with the
+ ... same filter and callbackUri already exists (in which case it shall return the "201 Created" response code), or may decide
+ ... to not create a duplicate subscription resource (in which case it shall return a "303 See Other" response code referencing
+ ... the existing subscription resource with the same filter and callbackUri).
+ Set headers {"Content-Type": "${CONTENT_TYPE_JSON}"}
+ Set headers {"Accept": "${ACCEPT_JSON}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ ${body_request}= Get File jsons/subscriptions.json
+ POST ${apiRoot}/${apiName}/${apiVersion}/subscriptions ${body_request}
+ ${output}= Output response
+ Set Suite Variable ${response} ${output}
+ Run Keyword If ${NFVO_CHECKS_NOTIF_ENDPOINT} == 1
+ ... Check Notification Endpoint
+
+
+Send Post Request for Duplicated NSD Performance Subscription
+ [Documentation] The POST method creates a new subscription
+ ... This method shall follow the provisions specified in the Tables 7.4.7.3.1-1 and 7.4.7.3.1-2 for URI query parameters,
+ ... request and response data structures, and response codes.
+ ... Creation of two subscription resources with the same callbackURI and the same filter can result in performance
+ ... degradation and will provide duplicates of notifications to the OSS, and might make sense only in very rare use cases.
+ ... Consequently, the NFVO may either allow creating a subscription resource if another subscription resource with the
+ ... same filter and callbackUri already exists (in which case it shall return the "201 Created" response code), or may decide
+ ... to not create a duplicate subscription resource (in which case it shall return a "303 See Other" response code referencing
+ ... the existing subscription resource with the same filter and callbackUri).
+ Set headers {"Content-Type": "${CONTENT_TYPE_JSON}"}
+ Set headers {"Accept": "${ACCEPT_JSON}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ ${body_request}= Get File jsons/subscriptions.json
+ POST ${apiRoot}/${apiName}/${apiVersion}/subscriptions ${body_request}
+ ${output}= Output response
+ Set Suite Variable ${response} ${output}
+ Run Keyword If ${NFVO_CHECKS_NOTIF_ENDPOINT}
+ ... Check Notification Endpoint
+
+
+
+Send Put Request for NSD Performance Subscriptions
+ [Documentation] This method is not supported. When this method is requested on this resource, the NFVO shall return a "405 Method
+ ... Not Allowed" response as defined in clause 4.3.5.4.
+ Pass Execution If ${testOptionalMethods} == 0 optional methods are not implemented on the FUT. Skipping test.
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ PUT ${apiRoot}/${apiName}/${apiVersion}/subscriptions
+ ${output}= Output response
+ Set Suite Variable ${response} ${output}
+
+
+Send Patch Request for NSD Performance Subscriptions
+ [Documentation] This method is not supported. When this method is requested on this resource, the NFVO shall return a "405 Method
+ ... Not Allowed" response as defined in clause 4.3.5.4.
+ Pass Execution If ${testOptionalMethods} == 0 optional methods are not implemented on the FUT. Skipping test.
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ PATCH ${apiRoot}/${apiName}/${apiVersion}/subscriptions
+ ${output}= Output response
+ Set Suite Variable ${response} ${output}
+
+
+Send Delete Request for NSD Performance Subscriptions
+ [Documentation] This method is not supported. When this method is requested on this resource, the NFVO shall return a "405 Method
+ ... Not Allowed" response as defined in clause 4.3.5.4.
+ Pass Execution If ${testOptionalMethods} == 0 optional methods are not implemented on the FUT. Skipping test.
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ DELETE ${apiRoot}/${apiName}/${apiVersion}/subscriptions
+ ${output}= Output response
+ Set Suite Variable ${response} ${output}
+
+
+Check HTTP Response Status Code Is
+ [Arguments] ${expected_status}
+ Should Be Equal ${response['status']} ${expected_status}
+ Log Status code validated
+
+
+
+Check HTTP Response Body Json Schema Is
+ [Arguments] ${input}
+ Should Contain ${response['headers']['Content-Type']} application/json
+ ${schema} = Catenate ${input} .schema.json
+ Validate Json ${schema} ${response['body']}
+ Log Json Schema Validation OK
+
+
+Check HTTP Response Body Is Empty
+ Should Be Empty ${response['body']}
+ Log No json schema is provided. Validation OK
+
+
+Check HTTP Response Body Subscriptions Match the requested Attribute-Based Filter
+ Log Check Response includes VNF Package Management according to filter
+ #TODO
+
+
+Check HTTP Response Body Matches the Subscription
+ Log Check Response matches subscription
+ ${body}= Get File jsons/subscriptions.json
+ ${subscription}= evaluate json.loads('''${body}''') json
+ Should Be Equal ${response['body']['callbackUri']} ${subscription['callbackUri']}
+
+
+Check Postcondition NSD Performance Subscription Is Set
+ Log Check Postcondition subscription exist
+ Log Trying to get the subscription
+ Set Headers {"Accept": "${ACCEPT_JSON}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${response['body']['id']}
+ ${output}= Output response
+ Set Suite Variable ${response} ${output}
+ Check HTTP Response Status Code Is 200
+
+
+Check Postcondition Subscription Resource URI Returned in Location Header Is Valid
+ Log Going to check postcondition
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ GET ${response.headers['Location']}
+ Integer response status 200
+ Log Received a 200 OK as expected
+ ${contentType}= Output response headers Content-Type
+ Should Contain ${contentType} application/json
+ ${result}= Output response body
+ Validate Json PmSubscriptions.schema.json ${result}
+ Log Validated PmSubscriptions schema
+
+
+
+Check HTTP Response Header Contains
+ [Arguments] ${CONTENT_TYPE}
+ Should Contain ${response.headers} ${CONTENT_TYPE}
+ Log Header is present
+
+
+Create Sessions
+ Pass Execution If ${NFVO_CHECKS_NOTIF_ENDPOINT} == 0 MockServer not started as NFVO is not checking the notification endpoint
+ Start Process java -jar ${MOCK_SERVER_JAR} -serverPort ${callback_port} alias=mockInstance
+ Wait For Process handle=mockInstance timeout=5s on_timeout=continue
+ Create Mock Session ${callback_uri}
+
+
+Check Notification Endpoint
+ &{notification_request}= Create Mock Request Matcher GET ${callback_endpoint}
+ &{notification_response}= Create Mock Response headers="Content-Type: application/json" status_code=204
+ Create Mock Expectation ${notification_request} ${notification_response}
+ Wait Until Keyword Succeeds ${total_polling_time} ${polling_interval} Verify Mock Expectation ${notification_request}
+ Clear Requests ${callback_endpoint}
diff --git a/SOL005/NSPerformanceManagement-API/Subscriptions.robot b/SOL005/NSPerformanceManagement-API/Subscriptions.robot
index 9baec607..f778e1a7 100644
--- a/SOL005/NSPerformanceManagement-API/Subscriptions.robot
+++ b/SOL005/NSPerformanceManagement-API/Subscriptions.robot
@@ -1,181 +1,81 @@
*** Settings ***
Documentation This resource represents subscriptions. The client can use this resource to subscribe to notifications related to VNF
... performance management and to query its subscriptions.
-Library JSONSchemaLibrary schemas/
Resource environment/variables.txt # Generic Parameters
-Library REST ${NFVO_SCHEMA}://${NFVO_HOST}:${NFVO_PORT}
+Resource environment/subscriptions.txt
+Resource NSPerformanceManagementKeywords.robot
Library OperatingSystem
+Library JSONSchemaLibrary schemas/
Library JSONLibrary
-Resource environment/subscriptions.txt
+Library REST ${NFVO_SCHEMA}://${NFVO_HOST}:${NFVO_PORT} ssl_verify=false
+Library MockServerLibrary
+Library Process
+Suite Setup Create Sessions
+Suite Teardown Terminate All Processes kill=true
*** Test Cases ***
-GET Subscription
- [Documentation] The client can use this method to query the list of active subscriptions to Performance management notifications
- ... subscribed by the client.
- ... This method shall follow the provisions specified in the Tables 7.4.7.3.2-1 and 7.4.7.3.2-2 for URI query parameters,
- ... request and response data structures, and response codes.
- Set headers {"Accept": "${ACCEPT_JSON}"}
- Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
- GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions
- Integer response status 200
- Log Received a 200 OK as expected
- ${contentType}= Output response headers Content-Type
- Should Contain ${contentType} application/json
- ${result}= Output response body
- Validate Json PmSubscriptions.schema.json ${result}
- Log Validated PmSubscription schema
+Get All NSD Performance Subscriptions
+ Get all NSD Performance Subscriptions
+ Check HTTP Response Status Code Is 200
+ Check HTTP Response Body Json Schema Is PmSubscriptions
+
+
+Get NSD Performance Subscriptions with attribute-based filter
+ Get NSD Performance Subscriptions with attribute-based filters
+ Check HTTP Response Status Code Is 200
+ Check HTTP Response Body Json Schema Is PmSubscriptions
+ Check HTTP Response Body Subscriptions Match the requested Attribute-Based Filter
+
+
+Get NSD Performance Subscriptions with invalid attribute-based filter
+ Get NSD Performance Subscriptions with invalid attribute-based filters
+ Check HTTP Response Status Code Is 400
+ Check HTTP Response Body Json Schema Is ProblemDetails
+
-GET Subscription - Filter
- [Documentation] The client can use this method to query the list of active subscriptions to Performance management notifications
- ... subscribed by the client.
- ... This method shall follow the provisions specified in the Tables 7.4.7.3.2-1 and 7.4.7.3.2-2 for URI query parameters,
- ... request and response data structures, and response codes.
- Set headers {"Accept": "${ACCEPT_JSON}"}
- Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
- GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions?${filter_ok}
- Integer response status 200
- Log Received a 200 OK as expected
- ${contentType}= Output response headers Content-Type
- Should Contain ${contentType} application/json
- ${result}= Output response body
- Validate Json PmSubscriptions.schema.json ${result}
- Log Validated PmSubscription schema
+GET NSD Performance Subscription with invalid resource endpoint
+ Get NSD Performance Subscriptions with invalid resource endpoint
+ Check HTTP Response Status Code Is 404
+
-GET Subscription - Negative Filter (Erroneous filter)
- [Documentation] The client can use this method to query the list of active subscriptions to Performance management notifications
- ... subscribed by the client.
- ... This method shall follow the provisions specified in the Tables 7.4.7.3.2-1 and 7.4.7.3.2-2 for URI query parameters,
- ... request and response data structures, and response codes.
- Set headers {"Accept": "${ACCEPT_JSON}"}
- Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
- GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions?${filter_ko}
- Integer response status 400
- Log Received a 400 Bad Request as expected
- ${contentType}= Output response headers Content-Type
- Should Contain ${contentType} application/json
- ${result}= Output response body
- Validate Json ProblemDetails.schema.json ${result}
- Log Validated ProblemDetails schema
+Create new NSD Performance subscription
+ Send Post Request for NSD Performance Subscription
+ Check HTTP Response Status Code Is 201
+ Check HTTP Response Body Json Schema Is PmSubscription
+ Check HTTP Response Body Matches the Subscription
+ Check Postcondition NSD Performance Subscription Is Set
+
-GET Subscription - Negative (Not Found)
- [Documentation] The client can use this method to query the list of active subscriptions to Performance management notifications
- ... subscribed by the client.
- ... This method shall follow the provisions specified in the Tables 7.4.7.3.2-1 and 7.4.7.3.2-2 for URI query parameters,
- ... request and response data structures, and response codes.
- Set headers {"Accept": "${ACCEPT_JSON}"}
- Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
- GET ${apiRoot}/${apiName}/${apiVersion}/subscription
- Integer response status 404
- Log Received a 404 Not found as expected
- ${contentType}= Output response headers Content-Type
- Should Contain ${contentType} application/json
- ${result}= Output response body
- Validate Json ProblemDetails.schema.json ${result}
- Log Validated ProblemDetails schema
+Create duplicated NSD Performance subscription with NFVO not creating duplicated subscriptions
+ [Tags] no-duplicated-subs
+ Send Post Request for Duplicated NSD Performance Subscription
+ Check HTTP Response Status Code Is 303
+ Check HTTP Response Body Is Empty
+ Check HTTP Response Header Contains Location
+ Check Postcondition Subscription Resource URI Returned in Location Header Is Valid
-POST Subscription
- [Documentation] The POST method creates a new subscription
- ... This method shall follow the provisions specified in the Tables 7.4.7.3.1-1 and 7.4.7.3.1-2 for URI query parameters,
- ... request and response data structures, and response codes.
- ... Creation of two subscription resources with the same callbackURI and the same filter can result in performance
- ... degradation and will provide duplicates of notifications to the OSS, and might make sense only in very rare use cases.
- ... Consequently, the NFVO may either allow creating a subscription resource if another subscription resource with the
- ... same filter and callbackUri already exists (in which case it shall return the "201 Created" response code), or may decide
- ... to not create a duplicate subscription resource (in which case it shall return a "303 See Other" response code referencing
- ... the existing subscription resource with the same filter and callbackUri).
- Set headers {"Content-Type": "${CONTENT_TYPE_JSON}"}
- Set headers {"Accept": "${ACCEPT_JSON}"}
- Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
- ${body_request}= Get File jsons/subscriptions.json
- POST ${apiRoot}/${apiName}/${apiVersion}/subscriptions ${body_request}
- Integer response status 201
- Log Received a 201 Created as expected
- ${contentType}= Output response headers Content-Type
- Should Contain ${contentType} application/json
- ${result}= Output response body
- Validate Json PmSubscription.schema.json ${result}
- Log Validated PmSubscription schema
- Log Trying to validate the Location header
- ${headers}= Output response headers
- Should Contain ${headers} Location
-POST Subscription - DUPLICATION
- [Documentation] The POST method creates a new subscription
- ... This method shall follow the provisions specified in the Tables 7.4.7.3.1-1 and 7.4.7.3.1-2 for URI query parameters,
- ... request and response data structures, and response codes.
- ... Creation of two subscription resources with the same callbackURI and the same filter can result in performance
- ... degradation and will provide duplicates of notifications to the OSS, and might make sense only in very rare use cases.
- ... Consequently, the NFVO may either allow creating a subscription resource if another subscription resource with the
- ... same filter and callbackUri already exists (in which case it shall return the "201 Created" response code), or may decide
- ... to not create a duplicate subscription resource (in which case it shall return a "303 See Other" response code referencing
- ... the existing subscription resource with the same filter and callbackUri).
- Pass Execution If ${NFVO_DUPLICATION} == 1 NFVO is permitting duplication. Skipping the test
- Set headers {"Content-Type": "${CONTENT_TYPE_JSON}"}
- Set headers {"Accept": "${ACCEPT_JSON}"}
- Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
- ${body_request}= Get File jsons/subscriptions.json
- POST ${apiRoot}/${apiName}/${apiVersion}/subscriptions ${body_request}
- Integer response status 303
- Log Received a 303 See other as expected
- ${contentType}= Output response headers Content-Type
- Should Contain ${contentType} application/json
- ${result}= Output response body
- Should Be Empty ${result}
- Log Body is empty
- Log Trying to validate the Location header
- ${headers}= Output response headers
- Should Contain ${headers} Location
-POST Subscription - NO DUPLICATION
- [Documentation] The POST method creates a new subscription
- ... This method shall follow the provisions specified in the Tables 7.4.7.3.1-1 and 7.4.7.3.1-2 for URI query parameters,
- ... request and response data structures, and response codes.
- ... Creation of two subscription resources with the same callbackURI and the same filter can result in performance
- ... degradation and will provide duplicates of notifications to the OSS, and might make sense only in very rare use cases.
- ... Consequently, the NFVO may either allow creating a subscription resource if another subscription resource with the
- ... same filter and callbackUri already exists (in which case it shall return the "201 Created" response code), or may decide
- ... to not create a duplicate subscription resource (in which case it shall return a "303 See Other" response code referencing
- ... the existing subscription resource with the same filter and callbackUri).
- Pass Execution If ${NFVO_DUPLICATION} == 0 NFVO is not permitting duplication. Skipping the test
- Set headers {"Content-Type": "${CONTENT_TYPE_JSON}"}
- Set headers {"Accept": "${ACCEPT_JSON}"}
- Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
- ${body_request}= Get File jsons/subscriptions.json
- POST ${apiRoot}/${apiName}/${apiVersion}/subscriptions ${body_request}
- Integer response status 201
- Log Received a 201 Created as expected
- ${contentType}= Output response headers Content-Type
- Should Contain ${contentType} application/json
- ${result}= Output response body
- Validate Json PmSubscription.schema.json ${result}
- Log Validated PmSubscription schema
- Log Trying to validate the Location header
- ${headers}= Output response headers
- Should Contain ${headers} Location
+Create duplicated NSD Performance subscription with NFVO creating duplicated subscriptions
+ [Tags] duplicated-subs
+ Send Post Request for Duplicated NSD Performance Subscription
+ Check HTTP Response Status Code Is 201
+ Check HTTP Response Body Json Schema Is PmSubscription
+ Check HTTP Response Body Matches the Subscription
+ Check Postcondition NSD Performance Subscription Is Set
-PUT Subscription - (Method not implemented)
- [Documentation] This method is not supported. When this method is requested on this resource, the NFVO shall return a "405 Method
- ... Not Allowed" response as defined in clause 4.3.5.4.
- Pass Execution If ${testOptionalMethods} == 0 optional methods are not implemented on the FUT. Skipping test.
- Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
- PUT ${apiRoot}/${apiName}/${apiVersion}/subscriptions
- Integer response status 405
- Log Received 405 Method not implemented as expected
-PATCH Subscription - (Method not implemented)
- [Documentation] This method is not supported. When this method is requested on this resource, the VNFM shall return a "405 Method
- ... Not Allowed" response as defined in clause 4.3.5.4.
- Pass Execution If ${testOptionalMethods} == 0 optional methods are not implemented on the FUT. Skipping test.
- Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
- PATCH ${apiRoot}/${apiName}/${apiVersion}/subscriptions
- Integer response status 405
- Log Received 405 Method not implemented as expected
+PUT NSD Performance Subscriptions - Method not implemented
+ Send Put Request for NSD Performance Subscriptions
+ Check HTTP Response Status Code Is 405
+
+
+PATCH NSD Performance Subscriptions - Method not implemented
+ Send Patch Request for NSD Performance Subscriptions
+ Check HTTP Response Status Code Is 405
+
+
+DELETE NSD Performance Subscriptions - Method not implemented
+ Send Delete Request for NSD Performance Subscriptions
+ Check HTTP Response Status Code Is 405
-DELETE Subscription - (Method not implemented)
- [Documentation] This method is not supported. When this method is requested on this resource, the VNFM shall return a "405 Method
- ... Not Allowed" response as defined in clause 4.3.5.4.
- Pass Execution If ${testOptionalMethods} == 0 optional methods are not implemented on the FUT. Skipping test.
- Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
- DELETE ${apiRoot}/${apiName}/${apiVersion}/subscriptions
- Integer response status 405
- Log Received 405 Method not implemented as expected
diff --git a/SOL005/NSPerformanceManagement-API/environment/variables.txt b/SOL005/NSPerformanceManagement-API/environment/variables.txt
index fc53947d..64de1566 100644
--- a/SOL005/NSPerformanceManagement-API/environment/variables.txt
+++ b/SOL005/NSPerformanceManagement-API/environment/variables.txt
@@ -9,10 +9,22 @@ ${apiRoot} /
${AUTH_USAGE} 1
${NEG_AUTHORIZATION} Bearer negativetoken
${apiVersion} v1
-${apiName} vnfpm
+${apiName} nspm
${FIELD_USAGE} 1
-${NFVO_DUPLICATION} 1
+${NFVO_CHECKS_NOTIF_ENDPOINT} 1
${MOCK_SERVER_JAR} ../../../bin/mockserver-netty-5.5.0-jar-with-dependencies.jar
-${testOptionalMethods} 0
\ No newline at end of file
+${testOptionalMethods} 0
+
+${callback_port} 9091
+${callback_uri} http://172.22.1.7:${callback_port}
+${callback_endpoint} /nspm/subscriptions
+${callback_endpoint_error} /subs_404
+${sleep_interval} 20s
+
+${total_polling_time} 2 min
+${polling_interval} 10 sec
+
+
+${response}
diff --git a/SOL005/NSPerformanceManagement-API/jsons/CreatePmJobRequest.json b/SOL005/NSPerformanceManagement-API/jsons/CreatePmJobRequest.json
index 1872a3bc..75549f53 100644
--- a/SOL005/NSPerformanceManagement-API/jsons/CreatePmJobRequest.json
+++ b/SOL005/NSPerformanceManagement-API/jsons/CreatePmJobRequest.json
@@ -1,10 +1,9 @@
{
- "objectInstanceIds" : ["1f50d68b-82e8-4deb-bd40-c934d4d1ac0a"],
- "criteria" : {
+ "objectInstanceIds": ["1f50d68b-82e8-4deb-bd40-c934d4d1ac0a"],
+ "criteria": {
"performanceMetric": [],
"performanceMetricGroup": [],
"collectionPeriod": 10,
- "reportingPeriod": 30,
-
+ "reportingPeriod": 30
}
}
\ No newline at end of file
diff --git a/SOL005/NSPerformanceManagement-API/jsons/subscriptions.json b/SOL005/NSPerformanceManagement-API/jsons/subscriptions.json
index 3fcc4e59..6293d99d 100644
--- a/SOL005/NSPerformanceManagement-API/jsons/subscriptions.json
+++ b/SOL005/NSPerformanceManagement-API/jsons/subscriptions.json
@@ -1,5 +1,5 @@
{
- "callbackUri": "http://127.0.0.1/subscribe",
+ "callbackUri": "http://172.22.1.7:9091/nspm/subscriptions",
"filter": {
"notificationTypes": ["ThresholdCrossedNotification"]
}
--
GitLab