| | | | |
|---|
| 1 | SO | Closed Loop | the "input-parameters" attribute of "service-instance" object described as: "String capturing request parameters from SO to pass to Closed Loop." | Closed loop scenario: SO will create “service-instance” object in AAI SO will store “customer-request” string on service-instance object in AAI When Closed Loop call recreates the “service-instance”, it will query “service-instance” information first, to get the “customer-request”
References |
| 2 | SO | ExtAPI | (see above?) | (see above?) |
| 3 | OOF | VFC | | scenario: VFC component sources the "flavor name" from OOF component Then VFC searches AAI using "flavor name" to find the corresponding "flavor id" Finally "flavor id" is used to create a VM
References |
| 4 | SDC | VID | | scenario: SDC distributes models into AAI Then VID calls custom query in AAI to get models by distribution status Finally VID uses models for its functions (this is the main flow for VID)
References |
| 5 | Multi-VIM / Cloud | OOF | | Scenario: Multi-VIM / Cloud collects Availability-Zone capacity data from Clouds into AAI OOF retrieves Availability-Zone information of each Cloud Region from AAI OOF makes homing / placement decisions for VNFs to support "teaming" use case
References |
| 6 | MultiCloud | OOF | | Scenario: MultiCloud collects HPA telemetry/time-series data into AAI OOF retrieves telemetry from AAI OOF makes decisions based on the telemetry
References: |
| 7 | VNFM / ESR | VIM / VFC | Question: | Scenario: VIM is registered to ESR including SSL certificates VNFM is registered to ESR including SSL certificates VFC retrieves connection details including SSL certificates VFC logs in to perform its control functions
References: |
| 8 | VID / SO / SDNC / OOF MultiCloud CLAMP / DCAE / DMaaP | VID / SO / SDNC / OOF MultiCloud CLAMP / DCAE / DMaaP | /cloud-infrastructure/cloud-regions/cloud-region/{cloud-owner}/{cloud-region-id} ‘cloud-region-id’ used in VID/SO/SDNC/OOF ‘cloud-owner’ + ’cloud-region-id’ used by AAI and its consumers ‘vim-id’ = {‘cloud-owner’}_{‘cloud-region-id’} used by MultiCloud and its consumers dcaeLocation used by CLAMP, DCAE and DMaaP
|
|
| 9 | MultiCloud | OOF | SR-IOV NIC from VIM sriov-pfs (SR-IOV physical functions, with relation to p-interface) sriov-vfs (SR-IOV virtual functions, with relation to l-interface) sriov-automation in cloud-region
| Scenario MultiCloud discovers SR-IOV NIC from VIM and registers it to AAI OOF gets cloud region ID, flavor id and physical nic alias from AAI OOF sends homing information to VF-C and SO
References |
| 10 | Policy | SO | | Scenario: Policy has parameters and references values. User manually inserts Dummy Incremental VF_Module into AAI containing the values SO retrieves values from AAI What happens to the Dummy Incremental VF_Module afterwards?
References: [Scaling] Scaling Automation Requirements
From: Scott Blandford
Date: Wed, 23 Jan 2019 16:52:31 UTC Scaling Team, Tech Mahindra is bringing some late requirements to the table for the Scaling Use Case. Fortunately, they are also bringing the resources to accomplish the goals. The goal is to automate some of the manual steps now required in the Scaling Use Case. The trickiest of these items is to eliminate the need for a Dummy Incremental VF_Module that needs to be inserted into AAI in order to pass the correct references in the Policy to SO API.
|
| 11 | External PNF manager? | DCAE / CLAMP / SO | | Scenario: External PNF manager discovers ONT and enters details into AAI DCAE / CLAMP correlate the ONT details to an existing PNF object in AAI and "nomadic ONT scenario" is recognised SO effectively moves the PNF / services to the new location
References: |
| 12 | SO | MultiCloud | Workload update (heatbridge) | Scenario: SO queries workload information either directly from OpenStack or via MultiCloud for various other cloud types SO or MultiCloud update the information to AAI AAI data is used for auditing (or something else?)
References: |
| 13 | DCAE | SDNC ExtAPI | BBS use case: https://groups.io/g/onap-bbs/topic/31027823 Using service-instance ID to retrieve customer ID. Updating service-instance status after receiving DCAE event.
| DCAE_CL_OUT event contains AAI data as a field "AAI\":{
\"attachmentPoint\":\"olt11-1-1\",
\"service-information.hsia-cfs-service-instance-id\":\"1923eaa8-8ab7-49ef-b4c2-e185efbbe832\",
\"cvlan\":\"1005\",
\"svlan\":\"100\",
\"remoteId\":\"some-remote-id\"
},
the value of "service-information.hsia-cfs-service-instance-id" can be queried in AAI using a Nodes query: GET
https://aai.api.simpledemo.openecomp.org:30233/aai/v14/nodes/service-instances/service-instance/03b92492-c5c0-487a-b414-d5427ab6f041?format=resource_and_urlwith the output results containing both a url and the service-instance resource object: {
"results": [
{
"url":
"/aai/v14/business/customers/customer/BBSCustomer/service-subscriptions/service-subscription/BBS_E2E_Service/service-instances/service-instance/03b92492-c5c0-487a-b414-d5427ab6f041",
"service-instance": {
"service-instance-id": "03b92492-c5c0-487a-b414-d5427ab6f041",
"service-instance-name": "BBS_E2E_Service",
...
}
}
]
}
The URL embeds the IDs of the customer, service-subscription and service-instance, without needing to do additional queries. This is useful for communicating to external systems through ExtAPI. The URL is also required to do a PUT call to update the status of the service-instance.
|
| 14 | tbc | etc |
|
|