...

Table of Contents
outline true style none

General requirements on PDP - implement the pub-sub for multiple policies per each component

1. maintain the database of subscribers with the
   1. list of generic policy-filters (each policy-filter is the resource from the request json to /decision/v1 API) Policy Design and API Flow for Model Driven Control Loop
   2. subscriber_topic for Message Router of DMaaP that uniquely identifies the component instance like “policies_DCAE_tca_<service-component-name>”
      1. <service-component-name> uniquely identifies the component in DCAE
2. if policy-update/add/remove matches any of the policy-filters, PDP would push the policy-update notification that contains the whole policy-body of each added/updated policy and policy-id of each removed policy to Message Router of DMaaP on policy -update/add/remove, the PDP would iterate through the subscribers and do its matching to any of the policy-filters on each subscriber the same way as /decision/v1 does
   push/delete from PAP
   1. select all subscribers that match to the pushed/deleted policies by any policy-filter
   2. for each affected subscriber retrieve all the latest snapshot of policies
   3. notify each subscriber_topic separately with the latest snapshot of policies by sending the message to Message Router of DMaaP with the topic=subscriber_topic
3. there might be a need for some logic to identify the stale subscriptions by checking with the Message Router of DMaaP on the timestamps of the latest delivered/undelivered message per ach topic PDP has the subscription onMessage Router of DMaaP will do the following
   
4. persistently (up to 7 days) deliver all the policy-update notifications per subscriber_topic
component will listen for the subscriber_topic of the topic PDP has the subscription on

...

General requirements on Message Router of DMaaP

1. persistently (up to 7 days) deliver all the policy-update notifications per subscriber_topic
2. component will listen for the subscriber_topic of the policy-update notification from MR of DMaaP with long-collect-polling time like 15 seconds to grab the push notification

...

Requirements on component

Less requirements on component - policy-handler to do the subscription with PDP for the component

1. on startup – subscribe to PDP with the policy-filter the component is interested in and the subscriber_topic=“policies_DCAE_tca_<service-component-name>” that that uniquely identifies the component instance
2. listen for subscriber_topic of policy-update notification from MR of DMaaP with long-collect-polling time like 15 seconds to grab the push notification
   Component instance would do the following
   1. on receiving the policy-update pushed notification from DMaaP, handle the policy-update that contains the whole policy-body of each added/updated policy and policy-id of each removed policy
3. on stop, unsubscribe subscriber_topic from PDP

...

More requirements on component (initial proposal)

1. on startup – subscribe to PDP with the policy-filter the component is interested in and the subscriber_topic=“policies_DCAE_tca_<service-component-name>” that that uniquely identifies the component instance
2. listen for subscriber_topic of policy-update notification from MR of DMaaP with long-collect-polling time like 15 seconds to grab the push notification
   
   1. on receiving the policy-update pushed notification from DMaaP, handle the policy-update that contains the whole policy-body of each added/updated policy and policy-id of each removed policy
3. on stop, unsubscribe subscriber_topic from PDP

See inside the diagram for more details, data structures, and flow steps

...