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 H 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 H 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 H 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.
    • Routing is needed, to ensure the request goes to the XACML-PDPs for a given tenant.
    • Load-balancing is needed so that load can be distributed across the XACML-PDPs for a given tenant.
  • 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.
  • 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.
  • DB information must be appropriately handled:
    • Policy types
      • XACML-PDP needs access to the policy types.  One solution is to change Xacml-PDP to pre-load required policy types instead of calling Policy DB.
    • Policies
      • Only needed by API & PAP, thus can remain in the central namespace
    • Operations History
      • Can be segregated by tenant
    • Distributed Locks
      • Can be segregated by tenant if locking is only required across a single tenant
      • Must address the multi-cluster case; perhaps use MUSIC for this case
  • No labels