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

Compare with Current View Page History

« Previous Version 2 Next »

Introduction

Dedicating pod, cluster or host to a specific domain means that the domain will have sole access to the dedicated pod, cluster or hosts such that scalability, security and manageability within a domain can be improved. The resources which belong to that tenant, will be placed into that dedicated pod, cluster or host.

Current Scenario

  • Currently in CloudStack, zones can be reserved for specific domains [

    http://bugs.cloud.com/show_bug.cgi?id=3386, ]. Only users in that domain or its subdomain may create guests in that zone. 
  • Dedicated Hosts and HA Hosts

    . [ 

    CS-14436 ]:  if one of the dedicated hosts fail then the VMs are HAed onto a specific host(s) that is dedicated for purposes of HA.
  • Domains cannot have private pod, private cluster or private host

Purpose

Dedicating a zone might be very expensive offering for several end-users whereas dedicating a pod/cluster/host may be more economical.

This feature will allow Root-Admin to dedicate resources to a specific domain that needs private infrastructure for additional security or performance guarantees.

This feature will enable a Domain to have private pod, cluster or host.

References

Feature Specifications

Private host, cluster, pod: 

  • Requirements: ** Dedicated Pods** Root Admin should be able to dedicate a pod to a particular domain.** Resources that belong to that dedicated pod will be accessible only to assigned domain's users.  
      • Resources that belong to the domain should use that dedicated Pod only.
      • Only VMs that belong to the domain/sub-domain accounts should be deployed/started on the hosts under the pod.
      • The Secondary Storage that provide storage for all the templates, ISO and Snapshots should be accessible to every pod whether it is dedicated or not.
      • If during a resource creation or start operation, there are no available resources in the pod, dedicated to the tenant then CloudStack should fail the operation. Appropriate error message should be logged and event generated.
    •  Dedicated Clusters** Root Admin should be able to dedicate a cluster to a specific domain.** Resources belonging to that cluster should be accessible to the users of that domain.
      • Only resources that belong to that domain/account should be deployed on the cluster.
      • Nodes in the same Cluster can live migrate instances to and from each other.
      • If during a resource creation or start operation, there are no available resources in the cluster, dedicated to the tenant then CloudStack should fail the operation. Appropriate error message should be logged and event generated.
    • Dedicated Hosts** Root Admin should be able to dedicate a host to a specific domain.** Resources belonging to that host should be accessible to the users of that domain.
      • Only VMs that belong to that domain/account should be deployed on the host.
      • Only VMs that belong to the tenant should be started on the host
      • If during a VM deploy or start operation, there are no available resources among the hosts dedicated to the tenant then CloudStack should fail the operation. Appropriate error message should be logged and event generated.  
    • Logs: Ensure proper logs are maintained into vmops.log and api.log 
  • Non-requirements: 
  • Test guidelines** Functional test
  • Configuration** No global configuration.
  • User permission** Only Root Admin will have the privilege to dedicate pod, cluster or host to specific domain.** If a user does not belong to a domain which has dedicated resources, he cannot access the pod, cluster or host dedicated to that domain.
    • Users belonging to domaint having dedicated resources, can access them but should not be allowed to modify.
    • TBD: Domain-Admin privileges.

Use Cases: 

Domain level accessibility of Dedicated Pod/Cluster/Host

Let D1 domain has SD1, SD2, SD3 sub-domains. A1 is the admin account, U2 is normal user account.

Here z1, z2, ... are zones ,  p1,p1, ... are pods, c1, c11, c2 ,.... are clusters, H1, H2, ... are Hosts 

z1 - (p1-c1,c11,c111),(p2-c2,c22),(p3-c3, c33)
z2 - (p4-c4)

Resource - Domain mapping

         ROOT               p1- c1,c11,c111,H1

             |________D1(A1,U2)

             |                     |                      p2- c2,c22,H2

             |                     |_______SD1(A3,U4,)                             c3,H3

             |                     |                     |_____________SD2(A5,U6)

             |                     |                                                     |_____________SD3(A7,U8)    

             |                     |_______SD11(A9,U10)

             |                     |

             |                     |_______SD12(A11,U12)

             |

             |_______D2(A13,U14)

                                z2, p4, c4 

  1. Root Admin must be able to dedicate a pod, cluster or host to any domain or sub-domain.
  2. Once a Zone is dedicated to a domain,  its pods and clusters will be dedicated to that domain eg: pod: p1 is dedicated to domain D1, clusters:c1, c11, c111 will be automatically dedicated to D1 by default.
  3. Sub-Domains SD1, SD2, SD3 should be able to deploy vm in clusters c1, c11, c111 or pod p1. 
  4. After dedicating pod p1 to domain D1, if further cluster c11 (in pod p1) is dedicated to SD3, then D1 or SD1 or SD2 should not be able to access c11. (Can SD3 use SD2, SD1 or D1's resources, verify)
  5. If another pod p2 is dedicated to SD1, then SD11, SD12 or D2 should not be able to access pod p2.
  6. Before dedicating a pod to a domain , check whether its zone is dedicated or not.
  7. Child Domain can access pod/cluster/host dedicated to parent domain, vice-versa is not (verify).
  8. If there is no available resources among the hosts dedicated to the sub-domain SD1 then operation should fail.##  However, root admin can modify a global parameter indicating if child domain can use from parent pool or not. (By Default the value should be false)
  9. If there are no available resources among the hosts dedicated to the domain or subdomain then CloudStack should fail the operation.

Architecture and Design description

API Changes:

Root Admin APIs

  • createPod
  • updatePod
  • listPods 
  • addCluster
  • deleteCluster
  • updateCluster
  • listClusters
  • addHost
  • updateHost
  • listHosts

Domain Admin/Users APIs

  • listPods 
  • listClusters
  • listHosts

Request parameter addition:

domainId of the domain to which the resources are dedicated. Required: false

DB Changes:

  1. Introduce one column “domain_id” in  host_pod_ref, cluster, host tables. Default value for domain_id should be null.

Design Decisions: TBD

UI flow

  • In "Add Pod" add a new option "Public" check option. If it is checked show 2 more list options of domain and account, set to the default value. 
  • In "Add Cluster" add a new option "Public" check option. If it is checked show 2 more list options of domain and account, set to the default value
  • In "Add Host" add a new option "Public" check option. If it is checked show 2 more list options of domain and account, set to the default value
  • Display isPublic flag when listPods, listClusters, listHosts. 
  • Set isPublic to true only when domainId or accountId is not null for the pod in the listPod response
  • No labels