Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

This page aims to describe the design, architecture & impacts of multi-tenancy support in Policy Framework project.

As discussed, in the last meeting (Friday, 10th July)

  • ONLY minimal impacting changes will be accepted in G release timeframe.

Current Blockers (which must be solved before proceeding)

  • DMaaP communication over multiple namespaces.
  • Policy DB communication over multiple namespaces. Mainly the security credentials generated randomly during DB pod creation.
  • Planning of what policy components needs to be centralized vs de-centralized and moved to tenant namespaces.
  • How DCAE/OOF or any other client decides which PDP engine to call for making decision. This is valid for scenarios where clients are making a REST (or any) call directly to PDP engine. Currently supported by Xacml-PDP.
  • Are there any impacts to CLAMP or any other clients who want to create/deploy policy in PDP Groups.
  • PDP in tenant namespace needs to check during initialization that DB is ready in the central namespace.
  • PDP → DB latency will increase if DB is in central namespace (Can be solved by splitting & moving DB to tenant namespace).

Scope for G release 

  • Create a PdpGroup per tenant. And decide which & how many PDP instances are needed depending upon the tenant needs. 
  • Deploy/Undeploy policies to specific tenant based PdpGroup. 
  • Manage multiple PdpGroup & PDP instances from PAP.
  • Health check for all PDP instances from PAP.

Limitations for G release (which will be solved in later releases) 

  • PDP engines will communicate to Policy DB in centralized namespace. Resulting in using same DB to store operations history data of multiple tenants.
  • One instance of drools-pdp can ONLY be configured to call a specific CDS instance for taking control loop actions using CDS actor.
  • No provision of authentication & authorization of user across multiple tenants.

Current proposed design (will evolve as we go)



Policy Weekly meeting updates (12th Aug 2020)

  • Need to figure out how Multi-Tenancy aligns with Multi-Cluster deployments.
  • Xacml-PDP needs load balancer for cases where numerous requests are generated by operational policy, resource instantiation etc.
  • There might be need for distributed locking in multiple PDPs inside tenant and also across tenant in case of multi cluster deployment.
  • Tenants are assumed to be use case/domain specific with their own Analytics component.
  • Tenants are assumed to only work towards specific devices for the use case/domain.
  •  Xacml-PDP needs to be changed to pre-load required policy types instead of calling Policy DB.
  • Need for Service Discovery or similar feature to make Xacml-PDP across multiple tenants resolvable by clients - DCAE, SDNC, Drools-PDP, OOF.
  • Need to verify how DCAE Analytics consume the Policy Update Notifications.  
  • No labels