Versions Compared

Old Version 3

changes.mady.by.user deepti dohare

Saved on

compared with

New Version 4

changes.mady.by.user deepti dohare

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Bug Reference

CLOUDSTACK-681

Branch

master, 4.1.0

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.

...

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 root dmin 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 hostdocument describes the specifications and design of this feature.

References

Feature Specifications

Private host, cluster, pod: 

...

Requirements

  1. Root Admins must

...

  1. be able to dedicate a zone, pod or cluster or host to a

...

  1. specific domain or account.
  2. A compute service offering could let an end-user select if dedication is required or not

...

  1. .
  2. Only VMs that belong to the domain/sub-domain accounts should be deployed/started on the hosts under the zone/pod/cluster/host.

...

  1. Only VMs that are requested with dedication flag can use those dedicated resources
  2. If during a VM deploy or start operation,

...

  1. there are no available resources

...

  1. among the

...

  1. hosts dedicated to the

...

  1. account 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.  

...

  2. Optionally, if implicit dedication flag is set for a zone, a new, unused host is found for fulfilling this request and added to the list of "dedicated" resource for this account and will be used for future fulfillment
  3. Migration of a VM to a resource not owned by the account must fail.
  4. Must be able to dedicate a primary storage to an account.

  

 

Service Offering requested with dedication ON 

Service Offering requested with dedication OFF

Account (or sub-domain or domain) has dedicated host/cluster/pod/Zone AND Implicit dedication flag ON 

Place VM in a dedicated area if space available; if no space in dedicated area, find a new free host and place VM and make the host part of the dedicated host for this account 

Place VM in a non-dedicated area 

Account (or sub-domain or domain) has NO dedicated host/cluster/pod/Zone AND Implicit dedication flag ON

find a new free host and place VM and make the host part of the dedicated host for this account to be used for future requests 

Place VM in a non-dedicated area

Account (or sub-domain or domain) has dedicated host/cluster/pod/Zone AND Implicit dedication flag OFF

Place VM in a dedicated area if space is available. if no space available in dedicated area, FAIL request 

Place VM in a non-dedicated area

Account (or sub-domain or domain) has NO dedicated host/cluster/pod/Zone AND Implicit dedication flag OFF

Fail the request 

Place VM in a non-dedicated area

Logs

  1. Ensure proper logs are maintained into vmops.log and api.

...

  1. log

Test Guidelines

  1. Dedicated resources can only be used if service offering dedication flag is ON.
  2. If resources are exhausted within a domain, VM deployment should fail if the Implicit dedication flag is OFF.

Configuration

  1. global configuration parameter addition: dedication.enable, default value for this is false.

User Permissions

...

  1. Only Root Admin will have the privilege to dedicate pod, cluster or host to specific domain or an account.

...

  2. 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/account.
  3. Users belonging to

...

  1. domain/account having dedicated resources, can access them but should not be allowed to modify.

...

  1. At this time, there is no requirement for the domain/sub-domain admins to manage the resource - the root admin will remain the owner of the resources

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 

...

  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

...

  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