R5 El Alto proposal for policy flows between the new PDP and DCAE component
- 1 Requirements on PDP - implement the pub-sub for multiple policies per each component
- 2 Requirements on Message Router of DMaaP - no changes to DMaaP seems to be required
- 3 Alternatives for requirements on component
- 3.1 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
- 3.2 Option - 5-2 - Less requirements on component - config-binding-service to call the policy-handler to do the subscription with PDP for the component
- 3.3 Option - 5-1 - Less requirements on component - policy-handler to do the subscription with PDP for the component
- 3.4 Option - 5 - More requirements on component (initial proposal) - too much to ask the components
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