VirtualClusterAPI

Work in Progress

1. Rationals
   1. There are many use cases of IaaS that require the provisioning of a group of compute/storage/network instances in order to satisfy the requirements of work loads from the tenants. These requirements include failure resilience, IO performance, redundancy, and security to name a few. Such requirements possess properties that go beyond the individual instance specification and thus should be expressed using constructs beyond individual instance such as "Server" and "Volume". For example, some users might want to have a web service cluster that contains a pair of redundant soft load balancers, a pair of redundant data base servers, and several web servers. To mitigate single device failure, the redundant servers should be placed in different hosts (or even racks and physical clusters). On the other hand, to achieve good throughput between the servers with different "roles", affinity rule should apply to the placement of any particular load balancer, data base server and web server. Such complicated requirements are difficult to express using the current construct.
   2. It is the responsibility of the platform rather than the users/tenants to find a good placement for these groups of instances. Users should worry about their high level requirements (capability requirements, QoS, SLA etc.), but not worry about details such as which host to avoid placing his/her VMs on.
   3. Current available provisioning unit is individual servers or volumes and requirements across multiple instances are enforced by scheduling hints (which are often not visible to users/tenants).
2. API specs
3. Implementation phases
4. Placement logic