Versions Compared

Key

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

...

References

  • Jira Legacy
    serverONAP System Jira
    columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId425b2b0a4733707d-557c2057-3c0c3a0f-b515ae5e-579789cceedb4fd8aff50176
    keyCPS-1616
  • Jira Legacy
    serverONAP System Jira
    columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId425b2b0a4733707d-557c2057-3c0c3a0f-b515ae5e-579789cceedb4fd8aff50176
    keyCPS-1615
  • Jira Legacy
    serverONAP System Jira
    columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId425b2b0a4733707d-557c2057-3c0c3a0f-b515ae5e-579789cceedb4fd8aff50176
    keyCPS-1812
  • Jira Legacy
    serverONAP System Jira
    columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId425b2b0a4733707d-557c2057-3c0c3a0f-b515ae5e-579789cceedb4fd8aff50176
    keyCPS-1865
  • Impl. Proposal for Merging of Subscriptions ( Positive Scenarios )

...


IssueNotes Decision
1Is it intended that CM Notification subscription request  cover (all) descendants of the given xpath too?!e.g.. if a child is removed and there is a subscription for the parent node, will a notification be send (grandchild, child leaf updates etc.) I hope NOT!
Consider:
  • Risk of client effectively subscribing to ALL data in a cm handle by specifying top level datanode(s)
  • Complexity (i.e. cost of) of merge operation. It might even required NCMP to check relevant dat model
  • Future use of wildcards, could be a viable alternative for including descendants

2Could xpath point to an element that does not exist (yet)if not how, how can I client be informed about a create event? 

3Should NCMP support re-homing, moving of a CM Handle from one DMI to another?assume only trough delete & create 

4CM Handle Delete: Should DMI or Clients be sent a subscription update 

do NOT delete dmi-subscription entry until owning subscription is deleted
(just ignore upon future delete if cm handle is gone altogether)

Note. LCM is already broadcast (today) 


  • Need to upgrade to CloudEevent format
  • Add subscription id (name+client id) to header (so client can filter)
5Validation of xpathoptions order of implement and also performance cost!
  1. none
  2. xpath-parser
  3. model check
  4. instance check

6can DMI plugin 'reject' a subscription create (for a given cm-handle-xpath combination)As NCMP might not validate as per issue#5 the DMI=plugin or component further down might have to reject an invalid xpath...

Priyank Maheshwari 

yes currently DMI can use response to say which cm handles are not accepted i.e. rejected' (but not 'pending') 

7implementation question: should 'rejected' DMI-subscriptions be storednot needed as whole subscription should be rejected

8Dimensioning of DB depends on #cm handles, #subscriptions and #xpaths per subscription, this could be too big for fast processing of updates! 

Need to agree maximum and possibly realistic average/total number of entries based on the characteristics  above
The team is blocked until this becomes clear as it will affect the way the data needs to be modelled exactly.



- kieran mccarthy- Dimensioning has been agreed.  See Characteristics

9Maximum (error) message sizetheoretically all cm handles and all xpaths combinations could be rejected or pending leading to a very large error message!

10can each CM-Handle have different set of xpath(s) per subscriptionthe  current 'basic' solution only supports a common set of datastore/xpaths (filter)

11can the same cm handle/xpath have different subscriptions with different datastores, does that affect the cm data notifications send (which datastore applies)
  • can register on any (passthrough) datastore
    • running
    • operational

  • compulsory, validation needed
  • part of KEY (unique entry) so cmHandle+datastore+xpath is the key 


Although this wiki-page will not be updated where cmHandle+xpath is mentioned as  unique entry etc. this should now include a third field: datastore as well.

12Will migration from 'basic' be supportedPreferred to ask customers to create new subscriptions

13list v list instances filtering

/p/c1
/p/c1[@key=23]
Are these different paths or not (from ncmp point of view)
*List instances might not always be supported, depending DMI Plugin impl.

14confirm subscription id (currently subscription name + client id)


15what subscription details should be send when there is a change (in the union)
  1. just delta
  2. just union
  3. union and delta (delta flagged) 

16one DMI rejects whole (see decision #6) subscription (affected cmhandles) but other DMI accepts the same subscription, is this possible how to handle

17What all datastores are supported ?

ncmp-datastore:passthrough-running or ncmp-datastore:passthrough-operational ??

or both?

  - kieran mccarthy  Both will be supported

18When NCMP sends subscription request to DMI and then DMI responds back to NCMP , do we need to have a correlationId to track/map the request and response? 

subscriptionId to be used.

Value: subscriptionID:DMIPluginName (Check if subscriptionId or DMIPlugin name doesn't contain a colon: ) - The seperator is to be chosen by the development team, will try with colon first. 

 

19

Which status codes to be used when the DMI Plugins respond back to NCMP ? 

We already have codes defined in NCMP. Do we reuse the same status codes when DMI Plugin responds back to NCMP with the subscription status ?

Yes, reuse. 

kieran mccarthy - Reuse the same codes defined in NCMP.  

20

Impl. Proposal for Merging of Subscription


 

Solution Proposal

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

...

Error-Upon-Error Combinations 

( To be captured as part of 
Jira Legacy
server

...

System Jira
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId

...

4733707d-

...

2057-

...

3a0f-

...

ae5e-

...

4fd8aff50176
keyCPS-1865
)


Previous InteractionCurrent InteractionExpectationNotesSign-Off
1any operation on non-existing cm-handleoperation for same non-existing cm-handlelisted in 'rejected' immediatelybehavior as normal

 

2create operation rejected by DMIcreate for same cm-handle/xpath Submit create request again. 

 

3create pendingcreate for same cm-handle/xpathSet it to pending without submitting a new request. When we get response for previous interaction it is applied for the current interaction as well. 

 

4create pendingdelete for same cm-handle/xpathSet an error 'Conflict/Busy'up to client to retry the operation. 

 

5delete pendingdelete for same cm-handle/xpathSet it to pending without submitting a new request. When we get response for previous interaction it is applied for the current interaction as well. 

 

6delete pendingcreate for same cm-handle/xpathSet an error 'Conflict/Busy'up to client to retry the operation. 

 

...