Table of Contents
outline true style none

...

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. on policy 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 on

...

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

...

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

   get the subscriber_topic=“policies_DCAE_tca_<service-component-name>”

   that that uniquely identifies the component instance

   from config-binding-service

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

3. 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 policyon stop, unsubscribe subscriber_topic from PDP

   the full snapshot of all the policies that match to the component

   1. calculate the delta between the current set of policies and the received shapshot of policies

...

More requirements on component (initial proposal) - too much

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

3. 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

   the full snapshot of all the policies that match to the component

   1. calculate the delta between the current set of policies and the received shapshot of policies

4. n on stop, unsubscribe subscriber_topic from PDP

...