Contributors

{"order":"name","contextEntityId":45307419}

Glossary

TermDefinition
producer-consumer pairings

Apart from "internal" AAI data, the data in AAI is produced by a non-AAI component and then consumed by another non-AAI component. Therefore the schema definitions and intended meanings of each schema element is not controlled by AAI itself.


References

Producer-Consumer Pairs


ProducerConsumerAAI RepresentationScenario and References
1SOClosed 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

2SOExtAPI(see above?)(see above?)
3OOFVFC
  • the "flavor name" attribute of "flavor" object
  • the "flavor id" attribute of "flavor" object

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

4SDCVID
  • /service-design-and-creation/models
  • custom query

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

5Multi-VIM / CloudOOF
  • /cloud-infrastructure/cloud-regions/cloud-region/{cloud-owner}/{cloud-region-id}/availability-zones

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

6MultiCloudOOF
  • HPA

Scenario:

  • MultiCloud collects HPA telemetry/time-series data into AAI
  • OOF retrieves telemetry from AAI
  • OOF makes decisions based on the telemetry

References:

7VNFM / ESRVIM / VFC
  • "ssl-cacert" attribute on /esr-system-info-list/esr-system-info/{esr-system-info-id}

  • vs "certificateUrl"

Question:

  • is it just a URL to a certificate file?
  • or is it the literal contents of a certificate file?

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


9MultiCloudOOF
  • 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

10PolicySO

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.

11External 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:

12SOMultiCloudWorkload 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:

13DCAE

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_url

    with 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.
14tbcetc



  • No labels

1 Comment

  1. In general, A&AI should be focused on inventory and topology data that reflects what is currently in the network.  I think we want to migrate some of this data out of A&AI; of course, that requires a good solution for where to put it.  Also, in general, if we look at flows of data as a request comes in to ONAP and is processed, it would be helpful to keep the architecture simple.  Might want to start with simplifying the architecture for where data is stored as SO orchestrates a request.