Schema Proposal

1. tbc

Code Proposal

1. In AAI, when the "orchestration-status", "service-instance-location-id", "input-params" for a Service Instance changes, notify ExtAPI so it does not need to poll AAI
   
   • AAI does have precedent for publishing events to DMaaP
   • ExtAPI to be updated to consume events from DMaaP
   • need to get agreement about topic configuration
   • Discuss with Adrian OSullivan and Ludovic Robert, to confirm whether existing AAI-EVENT topic in DMaaP suffices for this requirement

   • From Jimmy Forsyth (AT&T) to Everyone: 01:51 AM
     @Brian, yes, AAI sends notification on all changes to DMaaP to the AAI_EVENT (or maybe it’s AAI-EVENT) topic

   • AAI-1996 - Getting issue details... STATUS
   • EXTAPI-98 - Getting issue details... STATUS
   • James Forsyth  Can you please send us the details on what the format of the events are that are sent to DMaaP are from A&AI. For example is there only one topic called AAI-EVENT topic and any change on a service-instance is emitted to DMaaP.
    So regardless if the change is to orchestration-status or some other parameter, the AAI-EVENT is emitted. All pointers to any associated documentation, notes or code snippets appreciated.

   In the case you are interested in, the service-instance can be CREATED, UPDATED, or DELETED (which you find in “action” in the event-header) either as a standalone object or as part of a nested structure.  You can use the top-entity-type to tell you which is the containing object, and then use that to determine if a service-instance might be impacted by the operation.  In the case of a service-instance update, the top-entity-type will be either customer, service-subscription, or service-instance.

    

   For a customer or service-subscription, you would then look for a service-instance child object - in the example above, the service-instance would be in the position of the p-interface on a service-subscription and in the position of sriov-pf on a customer.  All of that depends on how the client uses the interface, and AAI has no control over it.  Since users can perform the operation at any of the 3 levels (with a DELETE object, sometimes there are rules about cascading deletes, I’d have to figure out of the customer/service-subscription/service-instance object hierarchy is subject to any of those rules (like it might not let you delete the service-subscription until all the service-instances are gone first; I just don’t recall the rules off the top of my head).

   Example of AAI-EVENT data

   {
       "cambria.partition": "AAI",
       "entity": {
           "fqdn": "test.onap.org",
           "hostname": "pserver-onap",
           "in-maint": false,
           "p-interfaces": {
              "p-interface": [
                  {
                      "in-maint":true,
                      "interface-name":"p-interface-02-test",
                      "resource-version":"1547072232613",
                      "sriov-pfs":{
                          "sriov-pf":[
                              {       
                          "pf-pci-id": "sriov-02-test",       
                          "resource-version":"1547072232613"
                              }
                          ]
                      }
                  },
                  {
                      "in-maint":true,
                      "interface-name":"p-interface-test",
                      "resource-version":"1547072232613",
                      "sriov-pfs":{
                          "sriov-pf":[
                              {
                                 "pf-pci-id": "sriov-test",
                                 "resource-version":"1547072232613"
                              }
                          ]
                      }
                  }
              ]
           },
           "resource-version": "1547072232618"
       },
       "event-header": {
           "action": "CREATE",
           "domain": "ONAP",
           "entity-link":"/aai/v14/cloud-infrastructure/pservers/pserver/pserver-onap",
           "entity-type": "pserver",
           "event-type": "AAI-EVENT",
           "id": "ece20816-1c1b-4f22-9192-62459ee170c5",
           "sequence-number": "0",
           "severity": "NORMAL",
           "source-name": "jimmy-curl",
           "timestamp": "20190109-22:17:12:660",
           "top-entity-type": "pserver",
           "version": "v14"
       }
   }

2. In client code using AAI API, make use of "nodes query" as shown in newly published documentation to optimise some queries on AAI data:
   • https://docs.onap.org/en/latest/submodules/aai/aai-common.git/docs/AAI%20REST%20API%20Documentation/nodesQuery.html
     
   • Ludovic Robert For example instead of
     • "GET /aai/v11/customers/{customerId}service-subscription/{service_subscriptionId}service-instance API/{service-instanceId}"
     • use "GET /aai/v11/nodes/service-instances/service-instance/{service-instanceId}" instead

     • From Jimmy Forsyth (AT&T) to Everyone: 01:51 AM
       @Adrian the answers are yes, service-instance-id is unique in ONAP and you can query it directly with the nodes query (see link above)

3. tbc