Versions Compared

Key

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

...

  • Jira Legacy
    serverSystem Jira
    columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keyCPS-1616
  • Jira Legacy
    serverSystem Jira
    columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keyCPS-1615
  • Jira Legacy
    serverSystem Jira
    columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keyCPS-1812
  • Jira Legacy
    serverSystem Jira
    columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keyCPS-1865
  • Impl. Proposal for Merging of Subscriptions CM Subscriptions : Creating/Merging( Positive Scenarios )

...

New Subscription changes forecasted for 25Q2.
Deliver current event based subscription discuss with wider stakeholders on  

Create DME subscription interfaces as a new subscription epic -[CPS-2233] CM Subscription with DME interface - ONAP Jira

 

Kolawole Adebisi-Adeolokun  to create backlog Jira

Requirements

Functional

...

Interface

...

Requirement

...

Additional Information

...

Requirements

Functional

(ids)

Interface

Requirement

Additional Information

Signoff
1CPS-E-08eNCMP will forward 'CM Notifications Subscription' LCM Create events to the appropriate DMI Plugins responsible for the CM Handles (ids) defined in the LCM Events. 
The message sent to DMI should include the private properties for each CM-Handle

 

2CPS-E-08e

NCMP will forward 'CM Notifications Subscription' LCM Delete events to the appropriate DMI Plugins responsible for the CM Handles

is defined in the LCM Events. 
The message sent to DMI should include the private properties for each CM-Handle.

A delete should only be forwarded if there is no other subscription for cmhandle datastore path.


 

23CPS-E-08eNCMP will forward 'CM Notifications Subscription' LCM Delete events to the appropriate DMI Plugins responsible for the CM Handles is defined in the LCM Events. 
The message sent to DMI should include the private properties for each CM-Handle.

A delete should only be forwarded if there is no other subscription for cmhandle datastore path.

 

3CPS-E-08eNCMP responds using Kafka message(s) with the result of the LCM operation
These messages will use agreed status fields:
  • StatusCode  (to be included in documentation)
  • responds using Kafka message(s) with the result of the LCM operation
    These messages will use agreed status fields:
    • StatusCode  (to be included in documentation)
    • StatusMessage
    • resulterrorInfo  (NEW to be fleshed out)

    Action: Define error details later
    Now in separate Epic, see 

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keyCPS-1865


    4CPS-E-08eAll events should use Cloud Events formathttps://cloudevents.io/

    5CPS-E-08eMessages should be processed in the order they are created (received)It will depend on DMIs responding within 30s.
    Subscription-id should be used as Kafka 'key' to ensure this.

    6CPS-E-08.eNCMP is to merge CM Notification Subscriptions create request and forward those to DMI plugin. (Interface to be added).
    • Prevent unnecessary subscription updates to nodes already involved in a subscription to the same path and datastore.
    • For possible combinations, see table below

    7CPS-E-08.e

    Last lights out: upon subscription Delete request only when there is no more subscription for a cm-handle & xpath & datastore combination a subscription-delete request will be sent to the relevant DMI(s).


    8CPS-E-08.eA single client subscription request should result into a maximum of one request per DMI. Of course there can be several messages if more than 1 DMI is involved.

    9CPS-E-08.eAmalgamate response should include rejected/accepted/pending DMI responses received within 30 seconds. A client shall be notified of available DMI subscription information after 30 seconds.  Subsequent DMI subscription updates shall be notified to clients as they become available.
    • Same schema for all notifications.
    • Subsequent notifications contains the state of all cmhandles involved in the subscription. 

    10CPS-NCMP-I-01CM Handle deletion should NOT update subscription details. Do NOT delete dmi-subscription entry until owning subscription is deleted, see issue #4 below

    11CPS-E-08.eBackward compatible with 'basic' created/delete operations.. 


    ...


    Error Scenario

    Expected behavior

    Sign-off

    1Non responding DMIs (configurable timeout)An error message listing the 'pending' CM Handle IDs. statusMessage/statusCode to be agreed. 
    2Non Existing or non-valid CM Handle IdsAn error message listing the 'rejected' CM Handle IDs.
    3DMI Plugin without CM Event subscription supportAn error message listing the 'rejected' CM Handle IDs 
    4Late Response (after timeout defined in #1) from DMIA list of outcomes (complete status on how many cmhandles are pending/rejected/accepted) from client subscription is returned in response. 

    statusMessage/statusCode to be agreed. 

     

    5Create for existing subscription idThe whole subscription will be rejected. statusMessage/statusCode to be agreed. 

     

    6Delete for non-existing subscription idThe whole delete subscription will be rejected. statusMessage/statusCode to be agreed. 

     

    7Error upon error

    An error scenario on a second subscription for the same cm-handle/xpath as a previous subscription which did not complete successfully (yet)

    to be discussed, see Error Upon Error Combinations


    Characteristics


    Parameter

    Expectation

    Notes

    Sign-off

    1Frequency of LCM Subscription EventsNo high volume of such events is expected
    For testing purpose 1 LCM event per minute would suffice.

    kieran mccarthy confirmed

     

    2Number of SubscriptionsMax: 200

    kieran mccarthy confirmed

    3CM Handles per Subscription

    Avg: 200

    Max: 500 (document only)

    kieran mccarthy to confirm
    Note: consider limit and future 'simple' ALL (wildcard) option when above that limit

    4Xpaths per Cm HandleAvg: 10

    5Status update processing time(Order of 30) seconds (NCMP side)

    ...


    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


    Descendent don't need to be taken into account

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

    xpath can point to an element that does not exist (yet)

    CPS/NCMP Does not need to check Xpath

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

    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) 


    No, subscription update

    • 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

    1. None
    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

    not 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 16521602

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

    ?? what was agreed ? Kolawole Adebisi-Adeolokun to update what was agree

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

    Yes, schema modification allows this

    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

    No, basic sub. will not be delivered as a separate feature 

    13list v list instances filtering

    /p/c1
    /p/c1[@key=23]
    Are these different paths or not (from ncmp point of view)

    List entries are unique.
    *List instances might not always be supported, depending DMI Plugin impl.

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

    previously was clientid and subcrioptionid and we were relying on concatenation of both to be unique

    Now only the event would contain subcrioptionid 

    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) 

    Just Delta

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

    Yes, this has been analysed

    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? 

    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. 

    subscriptionId to be used.


    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


    Schemas Agreed for the below events ( Source to Destination ) for the positive scenarios.

    1. DME to NCMP
    2. NCMP to DMI-Plugin
    3. DMI-Plugin to NCMP NCMP to DMEto NCMP 
    4. NCMP to DME
    21Create DME subscription interfaces Schema ChangeSchema Change, Events driven change now HTTP Rest. Study status is at 2/3 of review. CPS need to study new changes to subscription once study is approved. 

    New Subscription changes forecasted for 25Q2.
    Deliver current event based subscription discuss with wider stakeholders on  

    Create DME subscription interfaces as a new subscription epic -[CPS-2233] CM Subscription with DME interface - ONAP Jira

     

    Kolawole Adebisi-Adeolokun  to create backlog Jira

    Solution Proposal

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

    ...

    #Topic NameEnvironment VariableSourceDestinationNotes
    1
    subscription
    CM_SUBSCRIPTION_NCMP_CMIN_AVC_SUBSCRIPTIONTOPIC
    DMEDME/Client-Apps
    2
    ncmp-dmi-cm-avc-subscription-<dmi-name>
    NCMPCM_FORWARDSUBSCRIPTION_CMDMI_AVCIN_SUBSCRIPTIONTOPIC
    NCMPDMI Plugin
    3
    dmi-ncmp-cm-avc-subscription
    NCMPCM_RESPONSESUBSCRIPTION_CMDMI_AVCOUT_SUBSCRIPTIONTOPIC
    DMI PluginNCMP
    4
    subscription-response
    NCMPCM_OUTCOMESUBSCRIPTION_CMNCMP_AVCOUT_SUBSCRIPTIONTOPIC
    NCMPDME/Client-Apps
    5dmi-cm-events
    DMI_CM_EVENTS_TOPIC
    DMI PluginNCMPactual data notifications as per the subscriptions
    6cm-events
    NCMP_CM_EVENTS_TOPIC
    NCMPDME/Client-AppsNCMP to forward the notifications to the client-apps.

    Operation Specific Impl. Proposals

    Create and Merge

    Delete