Dedicated Resources - Private pod, cluster, host Functional Spec

Bug Reference

CLOUDSTACK-681

Branch

master, 4.1.0

Introduction

Dedicating pod, cluster or host to a specific domain/account means that the domain/account will have sole access to the dedicated pod, cluster or hosts such that scalability, security and manageability within a domain/account 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/Accounts 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/account  that needs private infrastructure for additional security or performance guarantees.

This document describes the specifications and design of this feature.

References

• PM document: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Private+Host%2C+Cluster%2C+Pod

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.

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: implicit.dedication.enable, default value for this is ON.

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. 
6. Only Root Admin can change the global parameter:  implicit.dedication.enable

Use Cases: 

Dedicating resources to Domain/Account:

Domain level accessibility:

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 should 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. Users in Sub-Domains SD1, SD2, SD3 should be able to deploy vm in parent domain's 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 (TBD).

Account level accessibility:

1. Once a pod/cluster/host is dedicated to an account, only users in that account can access it.
2. No other user from different accounts  in the same domain or different domain can access the resources. 

VM Deployment

1. If dedicated resources get exhausted for a domin/account, VM deployment will not fail unless shared resources has no free empty host, provided Implicit dedication flag: ON and service offering flag: ON.
2. VMs that belong to two different offerings can be on the same host as long as they belong to the same account/domain . For e.g. If an instance is deployed by account user and : 
            a. If that account has dedicated resources, service offering flag "isdedicated" checked, then VM will be deployed on the dedicated host having VMs of same account or on the host which is empty.
            b. If that account has NO dedicated resources, service offering flag "isdedicated" checked then VM will be deployed on the host which is empty and that host will become dedicated to this account.
3. The dedicated VM of other accounts (e.g. A2 or A3 ) of same domain or other domain, cannot use above host, but can use an empty host or host having vms of same account(A2 or A3). 
4. If the service offering flag if OFF, the VM  will be deployed as CloudStack is doing now but should not use the host marked "dedicated for domain/account x".
5. If no such host exists, VM operation should fail.

Architecture and Design description

This feature will come as a separate plugin which will use the PluggableService to add the DedicatedResources feature APIs into CloudStack, the DedicatedResourceManager will be responsible for thread scheduling and the DedicatedResourcePlanner which will implement a deployment planner interface.

Dedication will be achieved as:

1. Admin adds Pod/cluster/host
2. Admin dedicates the pod/cluster/host to a domain/account using new dedication APIs 
3. Admin enables the pod/cluster/host

Dedication will be used when:

1. If a request is placed to deploy a VM with Service Offering flag "isdedicated" ON.
   1. Check if the account/domain has dedicated resources:
      1. If Yes, Place the VM in dedicated resources.
      2. If No, Place the VM in new free empty host, make that host dedicated to that account.

Note: If Service Offering Flag is OFF, non-dedicated (shared) resources will be used.

API Changes:

Following new APIs will be added:

• Dedicating Resources to an account/domain
  • dedicatePod
  • dedicateCluster
  • dedicateHost
• Updating dedication of resources (removing dedication) 
  • updateDedicatedPod
  • updateDedicatedCluster
  • updateDedicatedHost
• Listing Dedicated resources per account/domain
  • listDedicatedPods
  • listDedicatedClusters
  • listDedicatedHosts

Existing API modification:

• createServiceOffering:  Request Parameter Addition:

DB Changes:

1. New Table : dedicated_resources (id, uuid, zone_id, pod_id, cluster_id, host_id, domain_id, account_id)|| Field || Type || Null || Key || Default || Extra ||

   id	bigint(20) unsigned	NO	PRI	NULL	auto_increment
   uuid	varchar(40)	YES	UNI	NULL
   data_center_id	bigint(20) unsigned	NO	MUL	NULL
   pod_id	bigint(20) unsigned	NO	MUL	NULL
   cluster_id	bigint(20) unsigned	NO	MUL	NULL
   host_id	bigint(20) unsigned	NO	MUL	NULL
   domain_id	bigint(20) unsigned	YES	MUL	NULL
   account_id	bigint(20) unsigned	YES	MUL	NULL

2. service_offering table: Introduce a column “isdedicated” in  service_offering table. Default value should be 0.

UI flow

• Add a check option in "Add Compute Offering" for is_dedicated flag.