R5 El Alto proposal for policy flows between the new PDP and DCAE component
Requirements on PDP - implement the pub-sub for multiple policies per each component
- maintain the database of subscribers with the
- list of generic policy-filters (each policy-filter is the resource from the request json to /decision/v1 API) TO BE DELETED - refer to Dublin Documentation#3.4PolicyDecisionAPI-GettingPolicyDecisions per component - subscriber
- subscriber_id should be able to globally and uniquely identify the component instance like “policies_DCAE_tca_<service-component-name>”.
- where <service-component-name> uniquely identifies the component in DCAE
- subscriber_topic for Message Router of DMaaP that
- either uniquely identifies the component instance like “policies_DCAE_tca_<service-component-name>”.
- or can be shared by all the components in DCAE like “policies_DCAE”. In this case the field ONAPInstance="<service-component-name>” can be used to identify the component instance
- option to return the policies on subscribe request
- option to have the matching /decision/v1 API that sends multiple policies per multiple policy-filters in a single query
- on policy push/delete from PAP and on the insert-update of the subscriber record
- select all subscribers that match to the pushed/deleted policies by any policy-filter
- for each affected subscriber retrieve all the latest snapshot of policies
- increment policy_update_seq value
- 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
- 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 - no changes to DMaaP seems to be required
- persistently (up to 7 days) deliver all the policy-update notifications per subscriber_topic
- 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
Alternatives for requirements on component
Alternative | impact on component | complexity for DCAE-Controller | comments |
---|---|---|---|
5 | highest - component to do the subscription and listen for policy-updates | minimal - only deliver the policy-filters and subscriber-topic for subscription | |
5-1 | less - component to listen for policy-updates | medium - k8s_plugin+policy-handler to do the subscription for policy-updates with PDP | drawback - no mechanism to bring the policies on the reboot of the component |
5-2 | less - component to listen for policy-updates | medium-high - config-binding-service+policy-handler to do the subscription for policy-updates with PDP | component can poll config-binding-service to get the latest policies either periodically or on reboot of the component |
5-3 | no impact - component as in Casablanca | highest - flow is comparable to Casablanca but is based on DMaaP instead of the web-socket and is per subscription for the component instead of matching policies to policy-filters in policy-handler |
Option - 5-3 - no impact requirements on component - the plugin and the policy-handler to do the subscription with PDP for the component and deliver the push notification about the policy-update the same way as in Casablanca
- single topic shared by all components of DCAE like “policies_DCAE”
- ONAPInstance value to identify the component instance in DCAE
- no impact on component - the same behavior as in Casablanca besides the new structure of the policy-body
- the policy-flow in DCAE-Controller resembles Casablanca with
- DMaaP instead of web-socket
- less communication chat inside DCAE-Controller
- and ONAPInstance matching to component deployment instead of policy-handler doing the rematch of policies to policy-filters/ids and deployment-handler to match the policy-filters/ids to component deployments
See inside the diagram for more details, data structures, and flow steps
Option - 5-2 - Less requirements on component - config-binding-service to call the policy-handler to do the subscription with PDP for the component
on startup – get the subscriber_topic=“policies_DCAE_tca_<service-component-name>” and the latest policies from config-binding-service
- initialize the policies in the component with policies received from config-binding-service - as it does now.
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
on receiving the policy-update pushed notification from DMaaP, handle the policy-update that contains the full snapshot of all the policies that match to the component
calculate the delta between the current set of policies and the received shapshot of policies
Config-binding-service to do the following on request from component
- get policy data from consul-kv
- request policy-handler to subscribe or get policies based on some flags in the blueprint to decide per component on whether to subscribe it to policy-updates or just bring the policies
- policy-handler will ask PDP to add the subscription and return the policies for the component or just get the policies for the component
- policy-handler to return the policies to config-binding-service
See inside the diagram for more details, data structures, and flow steps
Option - 5-1 - Less requirements on component - policy-handler to do the subscription with PDP for the component
on startup – get the subscriber_topic=“policies_DCAE_tca_<service-component-name>” from config-binding-service
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
on receiving the policy-update pushed notification from DMaaP, handle the policy-update that contains the full snapshot of all the policies that match to the component
calculate the delta between the current set of policies and the received shapshot of policies
See inside the diagram for more details, data structures, and flow steps
Option - 5 - More requirements on component (initial proposal) - too much to ask the components
- 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
- 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
on receiving the policy-update pushed notification from DMaaP, handle the policy-update that contains the full snapshot of all the policies that match to the component
calculate the delta between the current set of policies and the received shapshot of policies
- n stop, unsubscribe subscriber_topic from PDP
See inside the diagram for more details, data structures, and flow steps