Page History

...

1. Vmware datacenter will be put under management of CloudStack zone.
2. In this explicit model, CloudStack will understand the relationship between a Vmware datacenter and resources underneath it, so when resources like a Vmware cluster or dvSwitch that is added to CloudStack, the underlying Vmware resource relationship between these objects will become constraint information for CloudStack to use. For example, a Vmware cluster can't be added to a CloudStack zone if it's DC is not under the CloudStack zone, also an ASA1kv instance cannot be added to a Vmware cluster if its DC is not in the zone. The model itself will not limit how many Vmware clusters that a N1kv VSM instance or ASA1kv or vDS will manage, as long as N1kv or ASA1kv or vDS and its managed cluster are within the same DC.
3. CloudStack should be able to add/manage following DC level resources in scope of zone.
   1. Clusters
   2. Datastores for zone wide storage
   3. vDS/N1kv/ASA1kv (in future, see "Out of scope" section)
4. Upgrade to latest product (with this feature) does not enforce migration of existing CloudStack zones. This means that if an existing zone has clusters from multiple DCs/vCenters, it will be supported as-is. But zone wide features would not be supported on such zone. To quote some, zone wide primary storage, storage live migration across clusters in a zone.
5. During upgrade all zones with clusters from single DC would not be marked as legacy, otherwise marked as legacy.
6. Expansion of legacy zone is allowed. Expansion means adding more resources (like cluster).
7. A zone created after upgrade would be allowed to have only single DC.
8. New API would be added to associate a zone with a DC. Validation of DC name should happen during this operation.
9. New API would be added to dis-associate a zone from a DC.
10. Following constraint checks would be done while adding DC level resource (listed above) to zone. These constraints would not be applicable to legacy zones.
    1. Only clusters of the zone's associated DC can be added to a zone.
       1. Retrieve name of DC which encompasses this cluster. Compare the retrieved DC name with name of DC (being) associated with this zone.
    2. DC is not associated with any other zone already.
       1. Check guid, of new DC being added, doesn't already exist in table 'cloud'.'zone_vmware_data_center_map'. The guid is a string that encapsulates MOR of DC and vCenter host name/ip. By tracking both vCenter host name/ip and MOR of DC, it's possible to distinguish DC's across multiple vCenters.
    3. DC is not associated with any other CloudStack deployment.
       1. Check custom property over VMware's DC object if this DC is already associated with a zone of a CloudStack deployment. Custom property of type boolean can represent this, 'cloudstackzone'
11. While adding resource to cloudstack zone, approaches to apply constraint checks are,
    1. Track relationship between resources (DC <> Cluster <> DataStore <-> DVS etc.) in CloudStack database - suffices within single CloudStack deployment. Cannot detect if multiple CloudStack deployments are managing same resource (DC, DataStore etc.)
    2. Use custom property on VMware object as flag. This works across CloudStack deployments but proper cleanup is required upon removal.
12. During discovery process, VmwareServerDiscoverer might have to retrieve vCenter host/ip & credentials from database given zone_id, because they are made optional parameters because this data is already available in database when the zone is associated with first cluster. Construct connection url from this data.
13. While re-loading resource make sure connection url is defined correctly, could be retrieved from vmware_data_center table (guid).
14. If zone is disabled, no operations are allowed over that zone. Ex:- Add/remove cluster.
15. Associate DC to zone changes,
    1. Validate DC
    2. Validate zone
    3. Check if DC is associated with any other zone in current deployment.
    4. Check if DC's custom property 'cloudstackzone' is set to "true" or "false". If "true" fail the operation.
    5. Update database to add information of DC to table 'cloud'.'vmware_data_center'
    6. Update table 'cloud'.'zone_vmware_data_center_map' to associate DC with zone
    7. Set custom property over VMware DC object. If not already present, add boolean property 'cloudstackzone' with value 'true'. If the property is already present, just set it to 'true'. Now this DC cannot be associated with any other cloudstack zone.
16. Dis-associate zone from DC
    1. Check if all resources (clusters, N1kv etc.) of DC in zone are released, otherwise fail the operation.
    2. Set custom property over VMware DC object 'cloudstackzone' to 'false'
17. AddCluster changes
    1. No changes for legacy zone.
    2. All constraint checks would be done while attempting to add cluster to zone. DC information would be retrieved from 'cloud'.'vmware_data_center' table. DC to zone mapping information can be referred from 'cloud'.'zone_vmware_data_center_map'. Constraint checks would be added to VmwareServerDiscoverer.
    3. Update vmware DC properties in cloud.vmware_data_center table (Say DC name changes in vCenter)
    4. While adding VMware cluster to zone, check if a DC is already associated with that zone. If not, cluster add operation would fail. To achieve this, check if zone_vmware_data_center_map does have a row for the zone in question. If no such row exists, that means this zone is not yet associated with any DC.
18. DeleteCluster changes
    1. While deleting check if this is last cluster in the zone. If so, dis-association of DC to zone should be done. Hence do following,
       1. Cleanup tables cloud.zone_dc_map and cloud.vmware_dc for specific zone by removing entries by zone_id (if zone_id in row matches data_center.id then remove the row)
       2. Set the zone's corresponding DC object's property to 'false'. Now this DC can be associated with any other cloudstack zone.

...