Changes:
- Added 'virtualmachineid' parameter to the createVolume API to specify a VM for the volume. The Vm should be in 'Running' or 'Stopped' state.
- This parameter is used only when createVolume API is called using snapshotid parameter
- When this parameter is set, the volume is created from the snapshot in the pod/cluster of the VM. Also the volume is then attached to the VM in the same request
- If attach Volume fails but create has succeeded, the API errors out but the Volume created remains available. User may attach the same volume later
- When Vm is provided, but if no storage pool is available in the VM's pod/cluster then the volume is not created and API fails.
Resource limit shouldnt be counted for resources with display flag = 0. Adding functions to resourcelimitmanager and doing it for the volumes at the moment.
Even though the volume may get migrated from shared to local storage, it is not possible to update the disk offering.
The fix is to disallow migration from shared to local store.
VM deployment is fine, issue is in attach volume where all possible scenarios are not handled.
The following needs to be logic of attached volume:
1. if data volume scope is zone then allow attach (this is already there)
2. if data volume scope is cluster
a. if root volume scope is host, allow if both are in same cluster (already there)
b. if root volume scope is zone, allow if vm and data volume in same cluster (fixed as part of this commit)
3. if data volume scope is host allow if vm and data volume in same host (fixed as part of this commit)
Introduction of a new Transaction API that is more consistent with the style
of Spring's transaction managment. The existing Transaction class was renamed
to TransactionLegacy. All of the non-DAO code in the management server has been
updated to use the new Transaction API.
fix listDiskOffering to not display offerings to the normal users with forDisplay=false. But display them to ROOT Admin irrespective of the flag.
Added display flag in the updateVolume/offeirng commands
Signed off by : nitin mehta<nitin.mehta@citrix.com>
Various classes are using member injection to inject extensible objects.
Really those object should come from an AdapterList that is injected in.
This patch switches the code to use setter injection that will later allow
spring to inject an AdapterList or something similar to allow
extensibility.
Also fixed existing bugs for the API:
* corrected action event to be VOLUME.UPDATE (was VOLUME.ATTACH)
* all parameters to update, should be optional - fixed that. If nothing is specified, the db object will remain with its original fields
