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

Compare with Current View Page History

« Previous Version 5 Next »

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.

Current Scenario

  • Currently in CloudStack, zones can be reserved for specific domains. Only users in that domain or its subdomain may create guests in that zone. 
  • Dedicated Hosts and HA Hosts:  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 dmin to dedicate resources to a specific domain that needs private infrastructure for additional security or performance guarantees.

This document describes the specifications and design of this feature.

References

Feature Specifications

Requirements

  1. Root Admins must be able to dedicate a zone, pod or cluster or host to a specific domain or account.
  2. A compute service offering could let an end-user select if dedication is required or not.
  3. Only VMs that belong to the domain/sub-domain accounts should be deployed/started on the hosts under the zone/pod/cluster/host.
  4. Only VMs that are requested with dedication flag can use those dedicated resources
  5. If during a VM deploy or start operation, there are no available resources among the hosts dedicated to the account then CloudStack should fail the operation. Appropriate error message should be logged and event generated
  6. 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
  7. Migration of a VM to a resource not owned by the account must fail.
  8. 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.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 domain/account having dedicated resources, can access them but should not be allowed to modify.
  4. 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
  5. Only Root Admin can add a service offering with "isdedicated" option enabled. 

Use Cases: 

Dedication: Domain level accessibility of 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.VM Deployment:

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