cloudstack/setup/db/db
prachi 313e6ca284 Bug 8791 user dispersing allocator
Changes:
- Added a two new deployment planners  'UserDispersingPlanner' and 'UserConcentratedPodPlanner' to the DeploymentPlanners
- Planner can be chosen by setting the global config variable 'vm.allocation.algorithm' to either of the following values:
('random', 'firstfit', 'userdispersing', 'userconcentratedpod')
- By default, the value is 'random'. When the value is 'random', FirstFitPlanner is invoked as before that shuffles the resource lists.
- Now Admin can choose whether the deployment heuristic should be applied starting at cluster or pod level. This can be done by using the
global config variable 'apply.allocation.algorithm.to.pods' which is false by default. Thus by default as earlier, planner starts at clusters directly.

'UserConcentratedPodPlanner' changes:
- Earlier to 3.0, FirstFitPlanner used to reorder the clusters in case this heuristic was chosen.
- Now this is done by a separate planner and is applied only when 'vm.allocation.algorithm' is set to this planner
- It reorders the capacity based clusters/pods such that those pods having more number of Running Vms for the given account are tried first.
- Note that this userconcentration is applied only to pods and clusters. Not to hosts or storagepools within a cluster.

'UserDispersingPlanner' changes:
- 'UserDispersingPlanner' reorders the capacity ordered pods and clusters based on number of 'Running' VMs for the given account in ascending order. Aim is to choose thodes pods/clusters first which have less number of Running VMs for the given account
- Admin can provide weights to capacity and user dispersion so that both parameters get considered in reordering the pods/clusters. This can be done by setting
the global config parameter 'vm.user.dispersion.weight'. Default value is 1. Thus if this planner is chosen, by default, ordering will be done only by number of Running Vms, unless the weight is changed.
- HostAlllocators and StoragePoolAllocators also reorder the hosts and pools by ascending order of number of Running VMS/ Ready Volumes respectively for the given account. Thus try to choose that host or pool within a cluster with less number of VMs for the account.
2011-11-17 18:29:39 -08:00
..
data-217to218.sql Make cluster request timeout to be configurable 2011-07-14 18:23:23 -07:00
schema-20to21.sql Move all schema-*.sql to setup/db/db inline with db upgrade script 2011-04-01 15:47:16 -07:00
schema-21to22-cleanup.sql bug 10166: drop account_id/domain_id fields (if exist) in domain_router table 2011-06-06 13:55:50 -07:00
schema-21to22-premium.sql Full opensource 2011-08-23 19:52:19 -07:00
schema-21to22.sql Handle 2.1.x bugs when do 21x to 22x DB upgrade: 2011-06-08 14:59:19 -07:00
schema-22beta1to22beta2.sql Move all schema-*.sql to setup/db/db inline with db upgrade script 2011-04-01 15:47:16 -07:00
schema-22beta3to22beta4.sql Move all schema-*.sql to setup/db/db inline with db upgrade script 2011-04-01 15:47:16 -07:00
schema-217to218.sql bug 9610: Added VERSION table and related index change 2011-04-27 13:56:52 -07:00
schema-221to222-cleanup.sql Fixed upgrade bug related with the fact that some db upgrade steps were missed in 2.2.0/2.2.1 to 2.2.2 db upgrade 2011-05-19 15:37:59 -07:00
schema-221to222-premium.sql Full opensource 2011-08-23 19:52:19 -07:00
schema-221to222.sql bug 9658: added missing indexes to 2.1.x-2.2.x upgrade files 2011-05-01 12:54:23 -07:00
schema-222to224-cleanup.sql bug 9690: DB upgrade - dropped unused keys 2011-05-03 14:33:55 -07:00
schema-222to224-premium.sql Full opensource 2011-08-23 19:52:19 -07:00
schema-222to224.sql bug 9519 : add index to avoid table locking 2011-06-09 18:05:14 -07:00
schema-224to225-cleanup.sql Fixed bunch of db upgrade bugs. 2011-05-18 17:38:49 -07:00
schema-224to225.sql host_address in storage_pool should not have gotten the change to char(40) 2011-06-09 18:05:14 -07:00
schema-225to226.sql bug 10480, 10494: NPE fix in VirtualMachineManagerImpl, move keystore upgrade sql to upgrade225to226.sql 2011-06-28 15:00:34 -07:00
schema-227to228-premium.sql Full opensource 2011-08-23 19:52:19 -07:00
schema-227to228.sql Merge branch '2.2.y' 2011-08-22 20:28:30 -07:00
schema-228to229.sql bug 11253: 2011-08-26 15:21:29 +05:30
schema-229to2210.sql bug 11316: Removed new template upgrade changes. Added upgrade path from 2210 to 2211. Existing changes moved to 2211to2212 upgrade 2011-08-31 14:19:20 +05:30
schema-2210to2211.sql bug 11316: In 2.2.y, removed new template upgrade changes. Added upgrade path from 2210 to 2211. Moved existing changes to 2211to2212 2011-08-31 15:16:12 +05:30
schema-2211to2212-premium.sql bug 11938: don't index usage tables when do upgrade from 2211 to 2212. 2011-11-14 16:00:41 -08:00
schema-2211to2212.sql bug 11513: Fix public IP release in advance network 2011-09-21 19:16:41 -07:00
schema-2212to2213.sql bug 11573: made network wait timeout configurable 2011-11-09 13:14:27 -08:00
schema-2213to30-premium.sql bug 11173: Added usage for VPN users 2011-11-01 17:01:48 +05:30
schema-2213to30.sql Bug 8791 user dispersing allocator 2011-11-17 18:29:39 -08:00
schema-level.sql Move all schema-*.sql to setup/db/db inline with db upgrade script 2011-04-01 15:47:16 -07:00
schema-snapshot-217to224.sql bug 9617: fixed snapshot upgrade from 223 to 224 2011-04-29 14:13:25 -07:00
schema-snapshot-223to224.sql bug 9617: fixed snapshot upgrade from 223 to 224 2011-04-29 14:13:25 -07:00