Page History

...

1. Track relationship between resources (DC <-> Cluster <> DataStore <> DVS <> N1kv <-> ASA 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 cloustack deployments but proper cleanup is required upon removal.

• 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.

• While re-loading resource make sure connection url is defined correctly, could be retrieved from vmware_dc table (guid).

• AddCluster changes

1. If a row matches zone_dc_map.zone id and if DC name is not specified, DC name can be retrieved from vmware_dc table and used. If DC name is specified, validation of DC name should happen.
2. In VmwareServerDiscoverer, implement constraint checks while adding a cluster as mentioned in design section.
3. Update vmware DC properties in cloud.vmware_dc table (Say DC name changes in vCenter)
4. While adding VMware cluster to zone, check if zone_dc_map is empty or not. If empty, while adding this cluster we need to associate corresponding DC to zone. Hence do following,
   1. Update tables cloud.zone_dc_map and cloud.vmware_dc to associate DC with zone
   2. If N1kv instance is specified, update table cloud.virtual_supervisor_module and cloud.zone_vsm_map to assocaite N1kv VSM instance with zone
   3. 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.

• 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.

Database modifications

1. 'cloud'.'vmware_dc' table to track all DC specific information along with details of resources & vCenter. Implement Dao & VO for this table.
   1. Columns in this table are id, vCenter host/ip, DC name, DC Mor, guid
   2. id is primary key field of this table
   3. Implement Dao & VO for this table.
2. 'cloud'.'zone_dc_map' table will be added to persist the mapping of zone to DC.
   1. Columns in this table are id, vmware_dc_id, zone_id
   2. Foreign key id from vmware_dc table
   3. Foreign key id from data_center table
   4. Implement Dao & VO for this table.
3. 'cloud'.'cluster_vsm_map' would be removed.
4. 'cloud'.'zone_vsm_map' would be added. Also a zone can be associated with more than 1 VSM instances.
   1. Columns in this table are id, zone_id & vsm_id where id is Primary key of this table.
   2. Foreign key zone_id from data_center table.
   3. Foreign key vsm_id from virtual_supervisor_module table.
   4. Implement Dao & VO classes for this table.

...

1. AddCluster will be modified
   1. Interface perspective - Make parameters vCenter host/ip, credentials and DC name optional based on zone id's presence in zone_dc_map.

...