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
Check for the all the transition states for Maintenance. Also corrected the isMaintenance function for StoragePoolVo
Signed off by : nitin mehta<nitin.mehta@citrix.com>
Description:
Set the criterion for overriding/preserving the vmware.create.full.clone
flag so that if past version deployments have any deployments (data centers),
this flag will be set to false. Else, it will be set to true.
The earlier criterion to set this flag was based on the CS version numbers,
but that is not a good business logic to serve as a basis to set the flag.
Changes:
- In the upgrade path, for a private zone, entry needs to be added in the affinity_group_domain_map to provide access to the private zone for the domains it belongs too.
Changes:
- Implict creation of the 'ExplicitDedication' Affinity group during resource dedication
- Only one group per account or per domain will be present
- ListDedicatedResources by affinityGroup
- Deployment should consider dedicated resources associated to the group only
- Deleting affinity group should release the dedicated resouces
- Releasing the dedicated resources should remove the group associated if there are no more resources.
Conflicts:
plugins/dedicated-resources/src/org/apache/cloudstack/dedicated/DedicatedResourceManagerImpl.java
plugins/dedicated-resources/test/org/apache/cloudstack/dedicated/manager/DedicatedApiUnitTest.java
server/src/com/cloud/configuration/ConfigurationManagerImpl.java
Changes:
- 'ExcplicitDedication' type of group can be created/deleted by Root admin only
- Users can no longer create this type of affinity group
- RootAdmin can create this type of affinitygroup at domain level. Such a domain level group is available for all accounts in that domain for listing and for use during deployVM.
- The domain level affinitygroup should be visible to the users in that domain, domain admins and Root admin.
Conflicts:
server/src/com/cloud/api/query/QueryManagerImpl.java
server/src/org/apache/cloudstack/affinity/AffinityGroupServiceImpl.java
server/test/org/apache/cloudstack/affinity/AffinityApiUnitTest.java
On a fresh environment, some values in cloud.configuration table are persisted in com.cloud.server.ConfigurationServerImpl.persistDefaultValues()
A default value need to be set before com.cloud.upgrade.DatabaseUpgradeChecker
UI support for baremetal PXE server
CloudStack CLOUDSTACK-1364
UI support for baremetal DHCP server
Conflicts:
plugins/hypervisors/baremetal/src/com/cloud/baremetal/networkservice/BareMetalPingServiceImpl.java
plugins/hypervisors/baremetal/src/com/cloud/baremetal/networkservice/BaremetalKickStartServiceImpl.java
plugins/hypervisors/baremetal/src/com/cloud/baremetal/networkservice/BaremetalPxeManagerImpl.java
While upgrading to 4.2, the type of vswitch being used by each cluster is persisted to cluster_details table. This helps if user want to change the type of vswitch used in a zone or entire cloud later on but leave existing cluster continue to use old vswitches. Hence even after modifying the type of vswitch at cloud level (by modifying global configuration parameters) or modifying the type vswitch at zone level (by modifying the traffic label) would not disturb operation of existing clusters.
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
Edison Su
Nitin Mehta
Alena Prokharchyk
Harikrishna Patnala
Laszlo Hornyak
Alex Huang
Darren Shepherd
Wei Zhou
Prachi Damle
Daan Hoogland
Min Chen
Sanjay Tripathi
Kelven Yang
Vijayendra Bhamidipati
bharat kumar
frank
Kishan Kavala
Sateesh Chodapuneedi
Mike Tutkowski