You are viewing an old version of this page. View the current version .
Compare with Current
View Page History
Version 1
Next »
PDP would implement the pub-sub for policies per each component maintain the database of subscribers with thelist of generic policy-filters (==resource from the request json to /decision/v1 API) and the subscriber_topic for Message Router of DMaaP that uniquely identifies the component instance like “policies_DCAE_tca_<service-component-name> ” 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 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 with the topic that uniquely identifies the component instance like “policies_DCAE_tca_<service-component-name> ” 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 Message Router of DMaaP will do the followingpersistently (up to 7 days) deliver all the policy-update notifications per topiccomponent will listen for the topic of the 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 followingon startup – subscribe to PDP with the policy-filter the component is interested in and the DMaaP topic that would uniquely identify the component instance like “policies_DCAE_tca_<service-component-name> ”listen for topic “policies_DCAE_tca_<service-component-name> ” 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 whole policy-body of each added/updated policy and policy-id of each removed policyon stop , unsubscribe from PDP R5 El Alto proposal for policy flows between the new PDP and DCAE component PDP does the pub-sub for policies per component %date[yyyy-MM-dd HH:mm]% Policy-Engine DCAE DCAE-Controller deployment cloudify new Policy-Access-Point ( new PAP ) new Policy-Decision-Point ( new PDP ) maintains the table of policy-update subscribers with policy-filters and subscriber_topic pub-sub [0.3.2] insert-update the record for the subscriber_topic [0.3.3] return policies that match to policy-filters subscribe [99.2] delete the record for the subscriber_topic unsubscribe [1.0] iterate through all subscribers and policy-filters on each subscriber [1.1] select all added/updated/removed policies that match to any policy-filter on the subscriber_topic [1.2] notify each subscriber_topic separately with full policy_body of each updated/added policy and policy-id of each removed policy [1] on policy push/delete from PAP policy-update subscribers (table in database) subscriber_topic TEXT PK -- "policies_DCAE_tca_<service-component-name>" unique topic per each component instance ONAPName TEXT -- "DCAE" ONAPComponent TEXT -- "tca" ONAPInstance TEXT -- "<service-component-name>" policy-filters JSON -- list of the "resource" objects of /decision/v1: [{"policy-id": ["onap.scaleout.tca", "onap.restart.tca"]}, ...] list of policy-filters on subscriber_topic (component) DCAE component like TCA [0.3.1] get policy_engine_client config, subscriber_topic and all policy-filters along with the config from CBS [0.3.2] subscribe with PDP for policy-updates on all policy-filters and subscriber_topic ="policies_DCAE_tca_<service-component-name>" [0.3.3] use the policies that match to policy-filters [0.3] on startup - subscribe subscribe-listen for policy-update notifications from MR of DMaaP on subscriber_topic ="policies_DCAE_tca_<service-component-name>" with long-collect-polling time like 15 seconds to grab the push notification policy-update receiver [1.2] on receiving the push-notification of policy-update, handle and consume the added/updated/removed policies [99.2] unsubscribe subscriber_topic from PDP [99.2] on shutdown - unsubscribe consul-kv <service-component-name>: policies/filters /<filter_id>:{"policy-id": ["onap.scaleout.tca", "onap.restart.tca"]} <service-component-name>: policies/subscriber_topic ='policies_DCAE_tca_<service-component-name>' multiple policy-filters records ( "resource" objects of /decision/v1 API in PDP) per component policy_engine_client : {url, headers, tls-settings, timeout-settings, etc.} config of policy_engine_client in DCAE - populated on install of DCAE platform config_binding_service deployment_handler [0] install component through cloudify for the blueprint+inputs [99] uninstall component through cloudify cloudify k8s_plugin decorated with @policies_gather [0.1] @policies_gather : gather policy-filters assigned to component in blueprint+inputs [0.2] @policies_gather : save multiple policy-filters for component into consul-kv as <service-component-name>:policies/filters/<filter_id>:{"policy-id": ["onap.scaleout.tca", "onap.restart.tca"]} [0.3] k8s_plugin : install and start component [0] install component [99.1] @policies_gather : delete records from consul-kv [99.2] k8s_plugin : stop and uninstall component [99] uninstall component Message Router of DMaaP [1.2] persistently delivers the policy-update notification to each subscriber_topic with full policy_body of each updated/added policy and policy-id of each removed policy [0.3.2] http POST /decision/ subscription /v1/< subscriber_topic > for policy-updates with all the policy-filters and subscriber_topic ='policies_DCAE_tca_<service-component-name>' request to subscribe [0.3.3] http return policies that match to any of the policy-filters response to subscribe [0] install component [99] uninstall component [0] install component [99] uninstall component [0.2] save multiple policy-filters per component [99.1] delete records [0.3] start component [99.2] stop component [0.3.1] get policy_engine_client config, subscriber_topic and policy-filters along with the config [0.3.1] get policy_engine_client config, subscriber_topic and policy-filters along with the config [1] push/delete policies [0.3.2] sub [0.3.3] policies [0.3.2] sub [0.3.3] policies [0.3.2] subscribe insert/update subscriber record [1.0] iterate through all subscribers [99.2] unsubscribe delete subscriber_topic [1.2] push policy-update for DCAE component instance [1.2] push policy-update for DCAE component instance [99.2] http DELETE /decision/ subscription /v1/< subscriber_topic > no middleman (DCAE-Control) for policy update flow minimal number of messages and volume of data Message Router of DMaaP persistently delivers the push-notification of the policy-update per each component instance globally identified by subscriber_topic requirements on new PDP -- see the diagram maintain pub-sub table per subscriber_topic with policy-filters notify about the policy added/updated/removed through Message Router of DMaaP requirements on DCAE Component -- see the diagram on start, get the + policy_engine_client (when have <scn>:policies), + subscriber_topic (globally unique for the component instance like "policies_DCAE_tca_<service-component-name>") + and all the policy-filters assigned to the component instance from Config-Binding-Service (consul-kv) on start, subscribe directly with PDP for the policy-updates on the subscriber_topic on all the policy-filters assigned to the component instance on stop, unsubscribe subscriber_topic from PDP provide handler for the push-notification of the polciy-update received from Message Router of DMaaP listen for the policy-update notification on subscriber_topic coming through the Message Router of DMaaP with long polling collect-time requirements on Config-Binding-Service - new data from consul-kv get from consul-kv and return the + policy_engine_client (when have <scn>:policies), + subscriber_topic (globally unique for the component instance like "policies_DCAE_tca_<service-component-name>") + and all the policy-filters assigned to the component instance from Config-Binding-Service (consul-kv) requirements on @policies_gather -- see the diagram requirements on k8s_plugin -- see the diagram requirements on DCAE install put policy_engine_client config into consul-kv