2) Added new api - changeServiceForSystemVm - to support service offering upgrade for system vms
3) Removed global config parameters that are not in use anymore: consoleproxy.ram.size, consoleproxy.cpu.mhz, secstorage.vm.ram.size, secstorage.vm.cpu.mhz
-Allow for editing of traffic labels within the zone wizard; visible
by going to the create physical network(s) step and clicking the
'edit' button under each traffic type.
-Make hypervisor selection part of the create zone step, instead of
the add cluster step -- this is to allow the physical network UI to
have the selected hypervisor for the edit traffic labels dialog.
-Show drag-and-drop UI for basic zone setup, so that user can edit
traffic labels for a basic zone. Note that user can only have one
physical network here.
-Allow creation of storage traffic in a basic zone configuration, by
optionally dragging storage traffic type icon to first physical
network
status 14057: resolved fixed
status 14098: resolved fixed
status 14101: resolved fixed
status 14132: resolved fixed
-Add conditional CSS for Japanese version
-Fix font wrapping in JA CSS for header bar, system dashboard
-Add some missing localization labels
reviewed-by: jessica
Properly sync returned sticky fields from the API with the UI form, by
dynamically generating createForm fields based on Lb sticky
capabilities object; this will keep the required and conditional
fields properly up to date with the API requirements.
status 13765: resolved fixed
reviewed-by: jessica
-Complete localization for all UI elements, in en and ja
-Hide logo/EULA for OSS version, when no eula.html is present
-Language select on login screen
-Misc. fixes
reviewed-by: jessica
When elb capability is enabled on the network offering, we:
1) on each createLB command:
* associate ip address to the LB rule owner
* create LB rule
2) on each deleteLb command:
* delete the rule
* disassociate ip address
The rule belongs to the owner, so proper usage events are generated
2) Added elasticIp and elasticLb network capabilities. Provided support to create network offering with these capabilities.
3) Added one more default network offering having elasticip and elasticlb
4) Public network support to Basic zone. You can associate/disassociate IP addresses now
1. remove Garbagecollection primary storage allocator. other storage allocators fails may because there is primary storage with the same tag, it is not caused by no primary storage capacity.
2. delete template will try to delete templates in secondary storage in the API.
status 11497: resolved fixed
GarbageCollecting
Conflicts:
server/src/com/cloud/template/HyervisorTemplateAdapter.java
Revert "bug 10837: rename api related to netapp"
This reverts commit 5db6b500dd1bbb96bfddbd7eda6cf1f616e2e0f9.
Conflicts:
api/src/com/cloud/api/commands/MigrateVolumeCmd.java
client/tomcatconf/commands-ext.properties.in
Changes:
- Enabled updating storage tags
- All existing tags are wiped out and new ones provided are stored.
- Note that, if tags are updated on the storage, no changes are done to the deployment of already running VMs that were deployed prior to tag addition.
- Also added some validation to host tags update API.
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.
listSupportedNetworkServiceProviders returs list of services with providers and capabilities of each service.
It supports 2 parameters:
-service : list providers and capabilities of this service
-provider: list services of this provider
- if none is specified, lists all services supported
Alena Prokharchyk
frank
Brian Federle
Jessica Wang
bfederle
abhi
Nitin Mehta
kishan
anthony
Edison Su
Kelven Yang
Naredula Janardhana Reddy
Prasanna Santhanam
prachi
Murali Reddy