Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Id

Description

Pre-conditions

Test Steps

Expected Results

A: Health Checks for OOF-OSDF Components and Dependencies (Policy and OOF-HAS API)

A.1

Perform health check for the OOF-OSDF components using Health Check API

  •   OSDF Manager

[OSDF Manager]
EMULATORS-OR-SERVICES-ARE-UP

Server and authentication details should be configured at $OOF_HOME/config/feature-healthcheck.properties

SIMPLE-GET-HEALTH-CHECK-API

HTTP-200-TRUE

A.2

CHECK-REQ-OR-OPTIONAL
Perform health check for the following external components and OOF components using Health Check API:

  • Policy (external component)
  • OOF-HAS API (OOF component)

[Policy Emulator]
[
OOF-HAS API – container or emulator]
EMULATORS-OR-SERVICES-ARE-UP


SIMPLE-GET-HEALTH-CHECK-API

HTTP-200-TRUE

NOTE: Per comment and discussion with Ramki, removing this cell

TODO: Retain this cell till  and then remove it.


B: Fetch Data from Emulators (valid and invalid data, via GET and POST)

B.1

Retrieve response corresponding to "valid request" from HAS-API emulator

  • OSDF → HAS (POST data)

[OOF-HAS API – container or emulator]EMULATORS-OR-SERVICES-ARE-UP

SIMPLE-GET-POST-TO-EMULATORS-OR-SERVICES

TODO:

Payloads and Endpoint

Payload for OSDF-HAS request (based on SO-OOF/HAS Request Example below in section on payloads; Ankitkumar Patel to add the payload; Shankaranarayanan Puzhavakath Narayanan to review)

TODO: Endpoint and ports

Should receive a "request accepted" type response, following which we query status and the status should be a valid one (translating, translated, solving, solved, solution not found, etc.)


B.

Should receive response for valid request

TODO: Payloads

B.2

Retrieve response corresponding to "valid policy query" from Policy emulator

  • OSDF → Policy (POST query data)

[Policy]
EMULATORS-OR-SERVICES-ARE-UP

SIMPLE-GET-POST-TO-EMULATORS-OR-SERVICES

TODO: Payloads and Endpoint

Should receive response for valid policy query

TODO: Payloads

B.3

CHECK-REQ-OR-OPTIONAL
OSDF → Policy (bad result)
OSDF → HAS (GET; bad status)

Moved to another cell
OSDF → HAS (GET; solution found)

[Policy Emulator]
[OOF-HAS API – container or emulator]
EMULATORS-OR-SERVICES-ARE-UP

SIMPLE-GET-POST-TO-EMULATORS-OR-SERVICES

TODO: Payloads and Endpoint

Should receive corresponding responses

TODO: Payloads

C: Run Complete Requests for Different Applications

C.1SO → OSDF → HAS (well formatted request)

[Policy Emulator]
[OOF-HAS API – container or emulator]
EMULATORS-OR-SERVICES-ARE-UP

SIMPLE-GET-POST-TO-EMULATORS-OR-SERVICES

TODO: Payloads, Endpoint, and Call-Back URL

Should receive a valid Conductor reponse

TODO: Payloads

NOTE: Per comment and discussion with Ramki, removed tests for "malformed" requests (open to adding them later on as needed). Moved the remaining one to a separate cell.

TODO: Retain this cell till  and then remove it.


B.4C.2

Retrieve response corresponding to a decision from Conductor (i.e. "done" with either a solution found or no solution found):

OSDF → HAS (GET; solution found OR no solution found).

CHECK-REQ-OR-OPTIONAL
SO → OSDF → HAS (mal-formatted request or a data error so that the request goes through OSDF but fails at Conductor)Since we cannot guarantee whether a solution can be found (it is dependendent on dynamic state of the cloud instance), it may be better to merge it to a "solution found OR no solution found" – i.e. Conductor is done processing and gave a decision

[Policy Emulator]
[OOF-HAS API – container or emulator]
EMULATORS-OR-SERVICES-ARE-UP

SIMPLE-GET-POST-TO-EMULATORS-OR-SERVICES

TODO: Payloads , Endpoint, and Call-Back URL

Should receive a RequestError or an error from Conductor

TODO: Payloads

Example Request/Response Payloads for OOF-OSDF Functional Test Cases

and Endpoint

TODO: Check format of response and valid status messages

C: Run Complete Requests for Different Applications

C.1SO → OSDF → HAS (well formatted request)

[Policy Emulator]
[OOF-HAS API – container or emulator]
EMULATORS-OR-SERVICES-ARE-UP

SIMPLE-GET-POST-TO-EMULATORS-OR-SERVICES

TODO: Payloads, Endpoint, and Call-Back URL

Should receive a valid Conductor reponse

TODO: Payloads

C.2

CHECK-REQ-OR-OPTIONAL
SO → OSDF → HAS (mal-formatted request or a data error so that the request goes through OSDF but fails at Conductor)

[Policy Emulator]
[OOF-HAS API – container or emulator]
EMULATORS-OR-SERVICES-ARE-UP

SIMPLE-GET-POST-TO-EMULATORS-OR-SERVICES

TODO: Payloads, Endpoint, and Call-Back URL

Should receive a RequestError or an error from Conductor

TODO: Payloads

NOTE: Per comment and discussion with Ramki, removing this cell

TODO: Retain this cell till  and then remove it.

C.3

SO → OSDF → HAS → OSDF → Call Back URL

A valid request sent from SO to OSDF, which results in a valid template sent from OSDF to HAS. OSDF will then poll HAS till a decision is made (i.e. "done" with either a solution found or no solution found; it is probably difficult to ensure a solution is guaranteed – it is great if a solution is found, and it is OK for testing purposes even if there if no solution in some cases)

[Policy Emulator]
[OOF-HAS API – container or emulator] [SO-OOF-OSDF call-back receiver]

EMULATORS-OR-SERVICES-ARE-UP

[Policy Emulator]
[OOF-HAS API – container or emulator]
EMULATORS-OR-SERVICES-ARE-UP

Should receive a "done" type Conductor reponse (either successful in finding a solution or failed to find a solution, but Conductor made a decision either way)

TODO: Payloads

Example Request/Response Payloads for OOF-OSDF Functional Test Cases

Code Block
languagejs
themeEclipse
titleSO-OOF/HAS Request Example
linenumberstrue
collapsetrue
{
  "requestInfo": {
    "transactionId": "xxx-xxx-xxxx",
    "requestId": "yyy-yyy-yyyy",
    "callbackUrl": "https://so:5000/callbackUrl",
    "sourceId": "SO",
    "requestType": "create",
    "numSolutions": 1,
    "optimizers": ["placement"],
    "timeout": 600
  },
  "requestParameters": { "customerLatitude": 32.89748, "customerLongitude": -97.040443, "customerName": "xyz" },
  "placementDemands": [
    {
      "resourceModuleName": "vGMuxInfra",
      "serviceResourceId": "vGMuxInfra-xx"
Code Block
languagejs
themeEclipse
titleSO-OOF/HAS Request Example
linenumberstrue
collapsetrue
{
  "requestInfo": {
    "transactionId": "xxx-xxx-xxxx",
    "requestId": "yyy-yyy-yyyy",
    "callbackUrl": "https://so:5000/callbackUrl",
    "sourceId": "SO",
    "requestType": "create",
    "numSolutions": 1,
    "optimizers": ["placement"],
    "timeout": 600
  },
  "requestParameters": { "customerLatitude": 32.89748, "customerLongitude": -97.040443, "customerName": "xyz" },
  "placementDemands": [
    {
      "resourceModuleName": "vGMuxInfra",
      "serviceResourceId": "vGMuxInfra-xx",
      "tenantId": "vGMuxInfra-tenant",
      "resourceModelInfo": {
        "modelInvariantId": "vGMuxInfra-modelInvariantId",
        "modelVersionId": "vGMuxInfra-versionId",
        "modelName": "vGMuxInfra-model",
        "modelType": "resource",
        "modelVersion": "1.0",
        "modelCustomizationName": "vGMuxInfra-customeModelName"
      },
      "existingCandidates": { "identifierType": "service_instance_id", "identifiers": ["87257b49-9602-4ca1-9817-094e52bc873b"] },
      "excludedCandidates": { "identifierType": "service_instance_id", "identifiers": ["1ac71fb8-ad43-4e16-9459-c3f372b8236d"] },
      "requiredCandidatestenantId": { "identifierType": "service_instance_id", "identifiers": ["7e6c3e57-62cd-44f6-aa88-d0896998f7ec"] }
    },
    {
vGMuxInfra-tenant",
      "resourceModelInfo": {
        "resourceModuleNamemodelInvariantId": "vGvGMuxInfra-modelInvariantId",
        "serviceResourceIdmodelVersionId": "71d563e8-e714-4393-8f99-cc480144a05evGMuxInfra-versionId",
        "tenantIdmodelName": "vGvGMuxInfra-tenantmodel",
        "resourceModelInfomodelType": {"resource",
        "modelInvariantIdmodelVersion": "vG-modelInvariantId1.0",
        "modelVersionIdmodelCustomizationName": "vGvGMuxInfra-versionIdcustomeModelName",
        "modelName": "vG-model"},
      "existingCandidates": { "modelTypeidentifierType": "resourceservice_instance_id",
        "modelVersion"identifiers": "1.0",
 ["87257b49-9602-4ca1-9817-094e52bc873b"] },
       "modelCustomizationName": "vG-customeModelName"
      },
      "existingCandidates""excludedCandidates": { "identifierType": "service_instance_id", "identifiers": ["21d5f3e81ac71fb8-e714ad43-43834e16-8f999459-cc480144505ac3f372b8236d"] },
      "excludedCandidatesrequiredCandidates": { "identifierType": "service_instance_id", "identifiers": ["1ac71fb87e6c3e57-ad4362cd-4e1644f6-9459aa88-c3f372b8236dd0896998f7ec"] }
    },
    {
  "requiredCandidates": {    "identifierTyperesourceModuleName": "cloud_region_idvG",
      "identifiersserviceResourceId": ["TXAUS219"] }
    }
  ]"71d563e8-e714-4393-8f99-cc480144a05e",
  "serviceInfo": {
    "serviceInstanceIdtenantId": "d61b2543-5914-4b8f-8e81-81e38575b8ecvG-tenant",
      "serviceModelInforesourceModelInfo": {
        "modelInvariantId": "vCPEvG-invariantIdmodelInvariantId",
        "modelVersionId": "vCPEvG-versionId",
        "modelName": "vCPEvG-model",
        "modelType": "serviceresource",
        "modelVersion": "1.0",
        "modelCustomizationName": "vCPEvG-customeModelName"
    }
  },
  "licenseDemands": [
   "existingCandidates": {
      "resourceModuleNameidentifierType": "vGMuxInfraservice_instance_id",
      "serviceResourceIdidentifiers": "vGMuxInfra-xx"["21d5f3e8-e714-4383-8f99-cc480144505a"] },
      "tenantIdexcludedCandidates": { "identifierType": "vGMuxInfra-tenantservice_instance_id",
      "resourceModelInfoidentifiers": {["1ac71fb8-ad43-4e16-9459-c3f372b8236d"] },
      "requiredCandidates": { "modelInvariantIdidentifierType": "vGMuxInfra-modelInvariantId",cloud_region_id", "identifiers": ["TXAUS219"] }
    }
  ],
  "modelVersionIdserviceInfo": "vGMuxInfra-versionId",{
        "modelNameserviceInstanceId": "vGMuxInfra-modeld61b2543-5914-4b8f-8e81-81e38575b8ec",
    "serviceModelInfo": {
      "modelTypemodelInvariantId": "resourcevCPE-invariantId",
        "modelVersionmodelVersionId": "1.0vCPE-versionId",
        "modelCustomizationNamemodelName": "vGMuxInfravCPE-customeModelNamemodel",
      }"modelType": "service",
      "existingLicensesmodelVersion": {"1.0",
        "entitlementPoolUUIDmodelCustomizationName": ["87257b49-9602-4ca1-9817-094e52bc873b", "43257b49-9602-4fe5-9337-094e52bc9435"],
   vCPE-customeModelName"
    }
  },
  "licenseDemands": [
    {
      "licenseKeyGroupUUIDresourceModuleName": ["87257b49-9602-4ca1-9817-094e52bc873b"vGMuxInfra",
    "43257b49-9602-4fe5-9337-094e52bc9435"]
  "serviceResourceId": "vGMuxInfra-xx",
       }"tenantId": "vGMuxInfra-tenant",
    }
  ]
}
Code Block
languagejs
themeEclipse
titleSO-OOF/HAS Response Example
linenumberstrue
collapsetrue
{
  "transactionId  "resourceModelInfo": {
        "modelInvariantId": "xxxvGMuxInfra-xxx-xxxxmodelInvariantId",
  "requestId      "modelVersionId": "yyyvGMuxInfra-yyy-yyyyversionId",
  "requestState      "modelName": "completedvGMuxInfra-model",
        "statusMessagemodelType": "Success!resource",
  "solutions": {
      "placementSolutionsmodelVersion": ["1.0",
      {
        "resourceModuleName"modelCustomizationName": "vGMuxInfra-customeModelName",
        "serviceResourceId": "some_resource_id"},
        "identifierTypeexistingLicenses": "service_instance_id",{
        "identifierentitlementPoolUUID": ["1ac71fb887257b49-ad439602-4e164ca1-94599817-c3f372b8236d094e52bc873b",
        "assignmentInfo": ["43257b49-9602-4fe5-9337-094e52bc9435"],
          { "keylicenseKeyGroupUUID": "cloudOwner["87257b49-9602-4ca1-9817-094e52bc873b", "value": "amazon" },
43257b49-9602-4fe5-9337-094e52bc9435"]
      }
    }
  ]
}
Code Block
languagejs
themeEclipse
titleSO-OOF/HAS Response Example
linenumberstrue
collapsetrue
{
  "transactionId  { "key": "vnfHostNamexxx-xxx-xxxx",
  "valuerequestId": "ahr344gh" }yyy-yyy-yyyy",
          { "key"requestState": "isRehomecompleted",
  "valuestatusMessage": "FalseSuccess!" },
          { "key": "cloud_region_id", "value": "1ac71fb8-ad43-4e16-9459-c3f372b8236d" }"solutions": {
        ]"placementSolutions": [
      },
      {
        "resourceModuleName": "vGvGMuxInfra",
        "serviceResourceId": "some_resource_id",
        "identifierType": "cloudservice_regioninstance_id",
        "identifier": "2ac71fb81ac71fb8-ad43-4e16-9459-c3f372b8236d",
        "assignmentInfo": [
          { "key": "cloudOwner", "value": "amazon" },
          { "key": "cloud_region_idvnfHostName", "value": "1ac71fb8-ad43-4e16-9459-c3f372b8236dahr344gh" },
        ]
  {    }
    ],
    "licenseSolutions": ["key": "isRehome", "value": "False" },
      {
    { "key":   "resourceModuleName"cloud_region_id", "value": "vGMuxInfra",1ac71fb8-ad43-4e16-9459-c3f372b8236d" }
        "]
      },
      {
        "resourceModuleName": "vG",
        "serviceResourceId": "some_resource_id",
        "entitlementPoolUUIDidentifierType": "cloud_region_id",
        "identifier": ["1ac71fb82ac71fb8-ad43-4e16-9459-c3f372b8236d", "834fc71fb8-ad43-4fh7-9459-c3f372b8236f"],

        "assignmentInfo": [
          { "licenseKeyGroupUUIDkey": ["1ac71fb8-ad43-4e16-9459-c3f372b8236d", "834fc71fb8-ad43-4fh7-9459-c3f372b8236f"]"cloudOwner", "value": "amazon" },
          { "entitlementPoolInvariantUUIDkey": ["1ac71fb8-ad43-4e16-9459-c3f372b8236d", "834fc71fb8"cloud_region_id", "value": "1ac71fb8-ad43-4fh74e16-9459-c3f372b8236f"],c3f372b8236d" }
        ]
      }
  "licenseKeyGroupInvariantUUID  ],
    "licenseSolutions": ["1ac71fb8-ad43-4e16-9459-c3f372b8236d", "834fc71fb8-ad43-4fh7-9459-c3f372b8236f"]
      }{
    ]
  }
}

Test Planning for OOF Homing and Allocation Service (OOF-HAS)

All Functional Test Cases described here below will be automatized in the CSIT ONAP integration environment. OOF-HAS is a data driven component, this means that test cases and related results have dependency on A&AI network database content. For this reason OOF-HAS Functional Test cases divided in 2 groups according to OOF-HAS functionality definition status and dependency from A&AI: Test cases marked in Green are those that will be delivered as first set of Functional Test cases as they have limited dependencies on A&AI data set, those marked in white will be scoped by ONAP Beijing delivery final test steps where all components have better stability in the scope of Beijing release.

Note: for the moment we consider the whole OOF component as the contribution of 2 Docker Containers:

-       OSDF : handling “R” interface, which is invoked by SO

-       OOF-HAS: handling the internal “R’” interface, which in invoked by OSDF

    "resourceModuleName": "vGMuxInfra",
        "serviceResourceId": "some_resource_id",
        "entitlementPoolUUID": ["1ac71fb8-ad43-4e16-9459-c3f372b8236d", "834fc71fb8-ad43-4fh7-9459-c3f372b8236f"],
        "licenseKeyGroupUUID": ["1ac71fb8-ad43-4e16-9459-c3f372b8236d", "834fc71fb8-ad43-4fh7-9459-c3f372b8236f"],
        "entitlementPoolInvariantUUID": ["1ac71fb8-ad43-4e16-9459-c3f372b8236d", "834fc71fb8-ad43-4fh7-9459-c3f372b8236f"],
        "licenseKeyGroupInvariantUUID": ["1ac71fb8-ad43-4e16-9459-c3f372b8236d", "834fc71fb8-ad43-4fh7-9459-c3f372b8236f"]
      }
    ]
  }
}


Test Planning for OOF Homing and Allocation Service (OOF-HAS)

All Functional Test Cases described here below will be automatized in the CSIT ONAP integration environment. OOF-HAS is a data driven component, this means that test cases and related results have dependency on A&AI network database content. For this reason OOF-HAS Functional Test cases divided in 2 groups according to OOF-HAS functionality definition status and dependency from A&AI: Test cases marked in Green are those that will be delivered as first set of Functional Test cases as they have limited dependencies on A&AI data set, those marked in white will be scoped by ONAP Beijing delivery final test steps where all components have better stability in the scope of Beijing release.

Note: for the moment we consider the whole OOF component as the contribution of 2 Docker Containers:

-       OSDF : handling “R” interface, which is invoked by SO

-       OOF-HAS: handling the internal “R’” interface, which in invoked by OSDF


Id

Description

Pre-conditions

Test Steps

Expected Results

Status


N.1Name: Verify docker Containers are up and running

1. MUSIC (real ONAP) docker image is up and running

2. OOF-HAS docker image is up and running

Robot Framework is checking with "docker ps" command that all needed docker containers are up and in execution

N. 4 Docker Containers for music are Up and running (music-db, music-zk, music-war, music-tomcat)

N.5 Docker Containers for OPTF-HAS are up and running (cond-api, cond.solv, cond-cont, cond-data, cond-resv)

Implemented
N.2

Name: OOF-HAS Get root

Interface (R’).

Perform GET on root  "/" url

1. OOF-HAS docker image is up and running

Robot Framework is sending a REST call to OOF-HAS API – "/"

Method - GET

Endpoint: http://$(hostname ):8091/

OOF-HAS should respond with HTTP 200 and body containing "true"Implemented

N.3

Name: OOF-HAS Healthcheck

Interface (R’).

Perform healthcheck for OOF-HAS using Healthcheck REST API

1. OOF-HAS docker image is up and running

2. OOF-HAS configuration is performed

3. MUSIC (real ONAP) docker image is up and running

4. Music is prepopulated with Healthcheck row


Robot Framework is sending a Rest Call to MUSIC to Inject a Plan named "healthcheck"

Method - PUT

Endpoint: /MUSIC/rest/v2/keyspaces/conductor/tables/plans/rows?id=healthcheck


MUSIC should respond with HTTP 200

Implemented

Robot Framework is sending a REST call to OOF-HAS API – healthcheck

Method - GET

Endpoint: http://$(hostname ):8091/v1/plans/healthcheck

OOF-HAS should respond with HTTP 200 and body containing "true"Implemented
N.4

Name: OOF-HAS Wrong Version

Interface (R’).

Perform sanity sending a plan with wrong Version

Id

Description

Pre-conditions

Test Steps

Expected Results

N.1

Name: OOF-HAS Healthcheck

Interface (R’).

Perform healthcheck for OOF-HAS using Healthcheck REST API

1. OOF-HAS docker image is up and running

2. OOF-HAS configuration is performed

3. MUSIC (real ONAP) docker image is up and running

4. Music is prepopulated with Healthcheck row

Robot Framework is sending a REST call to OOF-HAS API – to Post a Plan

Method - POST

Endpoint: http://$(hostname ):8091/v1/plans

API – healthcheck

OOF-HAS should respond with HTTP 201 and body containing the plan acceptance (i.e. the plan is in “template” status and a unique identifier <planid> is returned)



Implemented

Robot Framework is sending a REST call to OOF-HAS API – to GET a final recommendations

Method - GET

Endpoint: http://$(hostname ):8091/v1/plans/

healthcheck

<planId>

OOF-HAS should respond with HTTP 200 and body containing "
true
the error reason"Implemented
N.
2
5

Name: OOF-HAS

Wrong Version

Missing Demand Section

Interface (R’).

Perform
sanity
Sanity sending a plan with
wrong Version
missing Demand Section

1. OOF-HAS docker image is up and running

2. OOF-HAS configuration is performed

3. MUSIC (real ONAP) docker image is up and running

4. Music is prepopulated with Healthcheck row

Robot Framework is sending a REST call to OOF-HAS

API – to Post a Plan

Method - POST

Endpoint: http://$(hostname ):8091/v1/

plans

plans

OOF-HAS should respond with HTTP 201 and body containing the plan acceptance (i.e. the plan is in “template” status and a unique identifier <planid> is returned)



Implemented
OOF-HAS should respond with HTTP 200 and body containing "the error reason"N.3

Name: OOF-HAS Missing Demand Section

Interface (R’).

Perform Sanity sending a plan with missing Demand Section

1. OOF-HAS docker image is up and running

2. OOF-HAS configuration is performed

3. MUSIC (real ONAP) docker image is up and running

4. Music is prepopulated with Healthcheck row

Robot Framework is sending a REST call to OOF-HAS

API – to

Post

GET a

Plan

final recommendations

Method -

POST

GET

Endpoint: http://$(hostname ):8091/v1/plans/<planId>

OOF-HAS should respond with HTTP 200 and body containing "the error reason"Implemented
N.
4
6

Name: OOF-HAS Wrong Constraint

Interface (R’).

Perform sanity sending a plan with wrong Constraints

1. OOF-HAS docker image is up and running

2. OOF-HAS configuration is performed

3. MUSIC (real ONAP) docker image is up and running

4. A&AI simulator docker image is up
and running and it is populated in such a way that OOF cache can be built
and running and it is populated in such a way that OOF cache can be built

Robot Framework is sending a REST call to OOF-HAS API – to Post a Plan

Method - POST

Endpoint: http://$(hostname ):8091/v1/plans

OOF-HAS should respond with HTTP 201 and body containing the plan acceptance (i.e. the plan is in “template” status and a unique identifier <planid> is returned)



Implemented

Robot Framework is sending a REST call to OOF-HAS

API – to

Post

GET a

Plan

final recommendations

Method -

POST

GET

Endpoint: http://$(hostname ):8091/v1/plans/<planId>

OOF-HAS should respond with HTTP 200 and body containing "the error reason"Implemented
N.
5
7

Name: OOF-HAS Correct plan no result

Interface (R’).

Send a correct plan requiring
vCPE
Optimization request for a set of Candidates and constraints that cannot be satisfied

1. OOF-HAS docker image is up and running

2. OOF-HAS configuration is performed

3. MUSIC (real ONAP) docker image is up and running

4. A&AI simulator docker image is up and running and it is populated in such a way that OOF cache can be built and that a set of recommendations can be returned

Robot Framework is sending a REST call to OOF-HAS

API – to Post a Plan

Method - POST

Endpoint: http://$(hostname ):8091/v1/plans



OOF-HAS should respond with HTTP
200
201 and body containing the plan acceptance (i.e. the plan is in “template” status and a unique identifier <planid> is returned)Implemented

Robot Framework is sending a REST call to OOF-HAS

API – to GET a final recommendations

Method - GET

Endpoint: http://$(hostname ):8091/v1/plans/<planId>

OOF-HAS should respond with HTTP 200 and body containing NO recommendations (i.e. the plan is in
“done”
“not found” status and no resources are returned back)Implemented
N.
6
8

Name: Correct Plan with recommendations

Interface (R’).

Send a plan requiring
vCPE
Optimization request for a set of Candidates

1. OOF-HAS docker image is up and running

2. OOF-HAS configuration is performed

3. MUSIC (real ONAP) docker image is up and running

4. A&AI simulator docker image is up and running and it is populated in such a way that OOF cache can be built and that a set of recommendations can be returned

Robot Framework is sending a REST call to OOF-HAS

API – to Post a Plan

Method - POST

Endpoint: http://$(hostname ):8091/v1/plans

OOF-HAS should respond with HTTP
200
201 and body containing the plan acceptance (i.e. the plan is in “template” status and a unique identifier <planid> is returned)Implemented

Robot Framework is sending a REST call to OOF-HAS

API – to GET a final recommendations

Method - GET

Endpoint: http://$(hostname ):8091/v1/plans/<planId>

OOF-HAS should respond with HTTP 200 and body containing the plan recommendations (i.e. the plan is in “done” status and a set of
optimized vCPEs is
recommendations are returned to the caller )Implemented






Appendix A: Overview of ONAP Testing Requirements

...