of new volumes. Following changes are implemented
1. Disable or enable a pool with the updateStoragePool api. A new 'enabled'
parameter added for the same.
2. When a pool is disabled the state of the pool is updated to 'Disabled'
in the db. On enabling it is updated back to 'Up'. Alert is raised when
a pool is disabled or enabled.
3. Updated other storage providers to also honour the disabled state.
4. A disabled pool is skipped by allocators for provisioing of new volumes.
5. Since the allocators skip a disabled pool for provisioning of volumes,
the volumes are also not listed as a destination for volume migration.
inconsistent state (NotUploaded or UploadInProgress) and doesn't transition to any terminal
state (Uploaded, Uploaded). As a result these volumes/templates cannot be removed. Fix is to handle such
volume/template entries correctly.
The copy command reply can have null size returned, so check and set values
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
(cherry picked from commit 53ca0b1861)
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
Set destination volume path as NULL while duplicating volume during migration.
If migration fails, destination volume will be marked as removed. And if migration succeeds, volume path will be rightly updated.
Fixed the following:
- Destroying volume in 'UploadAbandoned' state resulted in NPE
- Existing upload volume functionality interfered with this, added proper checks to prevent that
When we download volume then we create entry in volume_store_ref table.
We mark the volume entry to ready state once download_url gets generated.
When we migrate that volume, then again one more entry is created with same volume id.
Its state is marked as allocated. Later we try to list only one dataobject in datastore
for state transition during volume migration. If the listed volume's state is allocated
then migration passes otherwise it fails.
Below fix will remove the randomness and give priority to volume entry which is made for
migration (download_url/extracturl will be null in case of migration). Giving priority to
download volume case is not needed as there will be only one entry in that case so no randomness.
Update volume chain_info to NULL during cold migration.
Otherwise during VM start, CCP will configure and try to power-on the VM with wrong disk information.
While taking a snapshot of a volume, CS chooses the endpoint to perform backup snapshot operation by selecting any host that has the storage containing the volume mounted on it.
Instead, if the volume is attached to a VM, the endpoint chosen by CS should be the host that contains the VM.
on calling GetUploadParamsForVolume, persisting the metadata to db
validating the account limits and incrementing the appropriate limits
encoded the metadata on management server using preshared key
When a template a copied from a secondary to primary, we were trying to release a lock
twice, once in the create/copy base image function and in the create/copy base image
complete callback routine. This caused the exception as reported in the bug. Fixed by
updating the code make sure we release the lock in copy base image function only as
this is the place we took acquired the lock.
Devdeep Singh
Rajani Karuturi
Likitha Shetty
Koushik Das
Sanjay Tripathi
Rohit Yadav
Mike Tutkowski
Nitin Mehta
Abhinandan Prateek
Anshul Gangwar
Daan Hoogland
Min Chen
Hiroki Ohashi
Laszlo Hornyak
Edison Su
Prachi Damle
Damodar