While upgrading to 4.2 to support existing clusters working over standard vswitch or nexus dvswitch should be supported as is. To ensure this while upgrading to 4.2, existing cluster's vswitch configuration needs to be persisted to database. If zone level traffic label is empty then default vswitch name would be used.
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
Currently zones with multiple clusters from more than 1 hypervisor including VMware, are being ignored while processing them during upgrade.
If a zone has all non-VMware clusters then ignoring the zone is correct.
But if a zone has atleast 1 VMware cluster then make sure the zone processed further to mark it as legacy or associate the zone with appropriate VMware DC.
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
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>
only when there is portable IP range added at region level.
region response will now have details if portable IP service is enabled
or not. Portable IP service for a region is turned off by default. when
adming adds a portable ip range portable ip service is enabled for the
region.
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.
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.
Updating the new system template URLs for the existing templates during upgrade to 4.2.
If new 4.2 system template is registered before upgrade then marking the old templates as removed during upgrade.
Description:
Define upgrade paths from 4.1.0 to 4.1.1, and 4.1.1 to 4.1.2,
and 4.1.2 to 4.2.0. This new path will replace the existing
4.1.0 to 4.2.0 path. This is required to allow upgrades from
4.1.2 installations to 4.2.0. The 4.1.2 installation will have
that db version upon installation from the 4.1 branch. Please
note that these new upgrade paths are empty and don't make
any SQL schema modifications.
The time increased due to the newly added dedicated resources feature. During regular VM deployment, all dedicated resources are put in avoid list so that they are not considered for deployment.
Now the way to compute the list of dedicated resources is not optimal and performance deteriorates in an environment having lot of pods, clusters and hosts as the logic is to query db. for each suc resource.
The fix is to optimize the logic not to loop through all resources but get the list of each resource type in a single query.
Snapshot object is being accessed even when it is null. In case snapshot is not present in backup store the code should return after cleaning db entry.
Also noticed discrepancy in the upgraded db setup but couldn't fully verify it, so added logging in the upgrade logic for template/snapshots etc.
Track the Datacenter of previous cluster correctly while going through each cluster in the zone to see if 2 clusters are from different DC/vCenter.
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
System template upgrade is not required during 4.0 upgrade since we handle the same during 4.2 upgrade. So removing the system template update during 4.0 upgrade.
KVM.snapshot.enabled is lowercased by f025db95 to keep the configs
uniformly lower-case. But it missed the upgrade script and the
references in SnapshotManagerImpl. This commit will fix the issue in all
locations
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
Add the upgrade logic to populate the template/volume store ref table from upload table. We wont be using this table anymore.
Signed off by : nitin mehta<nitin.mehta@citrix.com>
Min Chen
Sateesh Chodapuneedi
Edison Su
Sanjay Tripathi
frank
Kishan Kavala
Vijayendra Bhamidipati
Alena Prokharchyk
Prachi Damle
Wei Zhou
Wido den Hollander
Likitha Shetty
Murali Reddy
Harikrishna Patnala
Koushik Das
Bharat Kumar
Marcus Sorensen
Rajesh Battala
Prasanna Santhanam
Kelven Yang
Nitin Mehta