Page History

...

• Jira
  server ONAP Jira columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key CPS-1616

• Jira
  server ONAP Jira columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key CPS-1615

• Jira
  server ONAP Jira columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key CPS-1812

• Jira
  server ONAP Jira columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key CPS-1865

• Impl. Proposal CM Event Subscription LCM: CreateImpl. Proposal CM Event Subscription LCM: DeleteSubscriptions : Creating/Merging( Positive Scenarios )

Requirements

Functional

Error

...

...

Handling 

...

...

1. Subscription Update scenarios for an ongoing subscription.
2. CM Notification Forwarding Check: When forwarding CM Notification NCMP will not check the content to see if the is a valid active subscription. It is assumed that the DMI Plugin as acted on the 'delete subscription' request (that request is NCMPs responsibility). And of course there wil be timing issues it also possible a CM Notification was send just after the subscription-delete was send (from client) but before the whole change had acted upon that. 
3. Retry: NCMP will only report when actions are pending or rejected. NCMP will not implement a retry mechanism
4. Wildcards: Wildcards or similar functionality where one string represent 0 or more xpaths is not covered as part of this requirement but it should be kept in mind as a future possibility
5. Dynamic Topic: Topic for CM Data Notifications back to client will be hardcode for now. 
   Study should consider compatibility with an 'ALL' cm handles options

Assumptions

1. The proposed Schema Change & HTTP Rest (reate DME subscription interfaces as a new subscriotion epic) has led to new epic which will be implemented in →  -[CPS-2233] CM Subscription with DME interface - ONAP Jira

Assumptions

Issues & Decisions

Solution Proposal

State handling for initial (basic)subscription create/delete use cases (not using concept of 'merging')

...

Scenario 1
1) Create Sub from Client: CH-1, CH-2
2) All handled by DM1
3) NCMP to DMI request Create sub:  CH-1, CH-2
DMI responds within 30 seconds: Status OK

NCMP Send message to client: Statsu OK (no list with Rejected/Pending)

...

Solution Proposal

State handling for initial (basic)subscription create/delete use cases (not using concept of 'merging')

Note. The above algorithm depends ons storing (in DB using yang modelled data) a cm-handle status for each cm-handle for each subscription!

Merge → Split

• NCMP treats a Client Subscription as one or more (small) DMI Subscriptions, each of which wil have there own state.
  Each DMI Subscription is related to 1 or more client subscriptions.
  If there is no more related client subscription the DMI Subscription can be deleted (once accepted by DMI Plugin)!

Data Model (not a great diagram...)

Create Combinations

Below examples demonstrate what should happen when two separate subscriptions operations are performed:

1. an operation on subscription 'A' for client id '10
2. an operation on subscription 'B' for client id '52'

NCMP Send message to client: Pending [CH-1, CH-2]

Scenario 3
1) Create Sub from Client: CH-1, CH-2
2) All handled by DM1
3) NCMP to DMI request Create sub:  CH-1, CH-2
DMI responds within 30 seconds: Rejected [CH-2]

NCMP Send message to client: Rejected [CH-2]

Scenario 4:
4 different DMIs each handling 2 Cm Handles, create sub for all CHs 

Scenario 4-part a
DMI1 CH-1, CH-2 All accepted within 30 secs
DMI2 CH-3, CH-4 Mixed result within 30 seconds e.g. Rejected [CH-4]
DMI3 CH-5, CH-6 No result after 30 seconds
DMI4 CH-7, CH-8 No result after 30 seconds

NCMP -> Client : Rejected [CH-4], Pending [ CH-5, CH-6, CH-7, CH-8 ]

4-part b
DMI3 PLugin responds after 40 seconds; status OK
NCMP -> Client : Rejected [CH-4], Pending [ CH-7, CH-8 ]

4-part c
DMI4 PLugin responds after 50 seconds; Rejected [CH-7]
NCMP -> Client : Rejected [CH-4, CH-7]

Note. The above algorithm depends ons storing (in DB using yang modelled data) a cm-handle status for each cm-handle for each subscription!

Merge → Split

• NCMP treats a Client Subscription as one or more (small) DMI Subscriptions, each of which wil have there own state.
  Each DMI Subscription is related to 1 or more client subscriptions.
  If there is no more related client subscription the DMI Subscription can be deleted (once accepted by DMI Plugin)!

Data Model (not a great diagram...)

...

Create Combinations

Below examples demonstrate what should happen when two separate subscriptions operations are performed:

1. an operation on subscription 'A' for client id '10
2. an operation on subscription 'B' for client id '52'

Create 'Merge' Diagram

Below diagram shows and example for two subscriptions with party overlapping CM Handles and XPaths.

...

* Note 1: given the possible combinations the message to DMI needs to be able to specify different xpaths per cm-handle. So a more complex structure is needed for this even ie. an array of CM Handles objects each having their own list of (target) xpaths!
Note 2: as per decision #11'datastore' should be included in all messages as well

Delete Combinations

Note 3: the correlation-id for message to and from to DMI will be composed from the subscription-id and the dmi-name

Delete Combinations

* Note:  as per decision #11'datastore' should be included in the 'DMI susbcription' data model too now. 

Error-Upon-Error Combinations

...

Client-Schema Update

Based on Issue#10 , the incoming schema from DME to NCMP should

• A single subscription contains multiple predicates
• Predicates should be an array of Predicates ( currently a single instance )
  • Each predicate contains an array of targets ( cmhandles) - as is.
  • Each predicate contains a single datastore (mandatory) 
  • datastore-xpath-filter should become an array of xpath-filters (instead of pipe separated single string)

Performance considerations

Below options (partly) explored dring CPS teem meeting 02 Aug 2023

• DMI record could reach in millions of instances
• In memory solution (ie hazelcast) can handle 10s - 100s of Megabytes (add some sample calc)
  • still need persistence if we don't have enough instances
• use many small messages reduce need for amalgamation
• amalgamated string-based solution.... 

Storage Solutions

Proposed Data Storage

Use a combination of

1. Database (yang modelled) for permanent subscription details, subscribers, predicates
2. In-Memory (hazelcast) for transient subscription details:  state (acceptep, rejected, pending)

Example Flow 1: First Subscription

...

We get a Subscription Create Request with unique subscription-id and a list of predicates(list of targets , datastore and list of filters)

{
"subscriptionId" : "A-10",
"predicates" : [
  {
    "targets": [ch-1,ch-2],
    "datastore" : "ncmp-datastore:passthrough-operational",
    "datastore-xpath-filter" : ["p1/c1","p2/c2"]
    },
  { "targets": [ch-3],
    "datastore" : "ncmp-datastore:passthrough-operational",
    "datastore-xpath-filter" : ["p3/c3"]
    }
]
 
}

Combinations 

( To be captured as part of 

Jira
server ONAP Jira columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key CPS-1865

)

Client-Schema Update

Based on Issue#10 , the incoming schema from DME to NCMP should

• A single subscription contains multiple predicates
• Predicates should be an array of Predicates ( currently a single instance )
  • Each predicate contains an array of targets ( cmhandles) - as is.
  • Each predicate contains a single datastore (mandatory) 
  • datastore-xpath-filter should become an array of xpath-filters (instead of pipe separated single string)

Performance considerations

Below options (partly) explored dring CPS teem meeting 02 Aug 2023

• DMI record could reach in millions of instances
• In memory solution (ie hazelcast) can handle 10s - 100s of Megabytes (add some sample calc)
  • still need persistence if we don't have enough instances
• use many small messages reduce need for amalgamation
• amalgamated string-based solution.... 

...

Example Flow 2: Second Subscription (merge)

We get a new subscription create request.

{
"subscriptionId" : "B-52",
"predicates" : [
  {
    "targets": [ch-2],
    "datastore" : "ncmp-datastore:passthrough-operational",
    "datastore-xpath-filter" : ["p2/c2" , "p3/c3"]
    }
]
}

...

1. DMI Plugin could either apply the whole subscription request or reject the whole subscription. i.e respond with accepted/rejected

...

Kafka Topics

subscription

CM_SUBSCRIPTION_NCMP_CMIN_AVC_SUBSCRIPTIONTOPIC

ncmp-dmi-cm-avc-subscription-<dmi-name>

NCMPCM_FORWARDSUBSCRIPTION_CMDMI_AVCIN_SUBSCRIPTIONTOPIC

dmi-ncmp-cm-avc-subscription

NCMPCM_RESPONSESUBSCRIPTION_CMDMI_AVCOUT_SUBSCRIPTIONTOPIC

subscription-response

NCMPCM_OUTCOMESUBSCRIPTION_CMNCMP_AVCOUT_SUBSCRIPTIONTOPIC

DMI_CM_EVENTS_TOPIC

NCMP_CM_EVENTS_TOPIC

Operation Specific Impl. Proposals

Create and Merge

• Impl. Proposal CM Event Subscription LCM: CreateSubscriptions : Creating/Merging( Positive Scenarios )

Delete

• Impl. Proposal CM Event Subscription LCMSubscriptions : Delete ( Positive Scenarios )