...

Domain D1 , Account A1 and  Project P1

Point to remember: When we refer Primary/Seconday storage space, it means the stated size of the volume and not the physical size i.e actual consumed size on disk (in case of thin provisioning).

1. Number of CPUs:

1. 1. Root/Domain-Admin update CPU to 10 for domain D1. Users belonging to Domain D1 should not be able to use more than that.
   2. Root/Domain-Admin update CPU to 10 for Account A1 in Domain D1. Users belonging to Account A1 should not be able to use more than that. Also, they should not cross CPU limit defined for D1 domain.
   3. Limits imposed on Domain D1 should be imposed on sub-domain SD1 as well.
   4. Root/Domain-Admin update CPU to 10 for Project P1 having account A1 . Users belonging to Project P1 should not be able to use more CPUs than the defined limit.

...

1.  
   1. Root/Domain-Admin update network bandwidth rate to 200mbps for domain D1. Users belonging to Domain D1 should not be able to use more than that.
   2. Root/Domain-Admin update network bandwidth rate to 200mbps for Account A1 in Domain D1. Users belonging to Account A1 should not be able to use more than that. Also, they should not cross network bandwidth rate limit defined for D1 domain.
   3. Limits imposed on Domain D1 should be imposed on sub-domain SD1 as well.
   4. Root/Domain-Admin update network bandwidth rate to 200mbps for Project P1 having account A1. Users belonging to Project P1 should not be able to use more network bandwidth rate than the defined limit.

6. If admin reduces the total no. of VM resource limit for an account and set it to less then the total no. of currently running VMs under that account, the existing behaviour resources currently consumed by that account, under this scenario, CS would not destroy the existing VMs/templates/volumes etc. using those resources, it only impose limits if user under that account tries to execute some new operation.  For e.g., in case of VM, the existing behavior of CS for the following commands are:

1.  
   1. migrateVirtualMachine: User under that account will be able to migrate the running VM into any other host without facing any limit issue.
   2. recoverVirtualMachine: If user destroy one of the running VMs and later if he tries to recover it, CS will not allow this operation.

7. For any resource type, if a domain has limit X, sub-domain/accounts under that domain can have there own limits, but at any point of time the sum of resource allocated to sub-domain/accounts under the domain should never exceed the value X.
For e.g., if a domain has CPU limit of 40 and sub-domain D1 and account A1 can have limits of 30 each, but at any point of time the resource allocated to D1 and A1 should not exceed the limit 40.

8. If any operation needs to pass through two of more resource limit check, then the lower of 2 limits will be enforced, For e.g. if an account has VM limit of 10 and CPU limit of 20 and user under that account requests 5 VMs of 4 CPUs each, after this user can deploy 5 more VMs(because VM limit is 10) but user has exausted his CPU limit and cannot deploy any more instance.

Architecture and Design description

...