Data populated to VM Instances under "cmdb_ci_vm_instance" table
- The records under "cmdb_ci_vm_instance" table have below fields
- DiskSizeObject ID
- It is observed that some of the VMs could able to populate with all the above details and some could be missing to populate the data.
- Below is the process of populating the data to the fields of each VM instance under "cmdb_ci_vm_instance"
- Every VM under "cmdb_ci_vm_instance" table should be provisioned with a hardware template
- The hardware template id associated with all the VM's in "cmdb_ci_compute_template" table.
- The response mapping for "cmdb_ci_vm_instance" table for the above fields is a scripted one that makes a query to the "cmdb_ci_compute_template" table using the hardware id as the query parameter.
- The issue is that while discovering Hardware Templates, the templates might not have all the required information populated and while the VM discovery happens from the method ListNodes, the hardware id associated with the Hardware template will not have the data and hence the VM instance doesn't populate all the information.
- If the associated hardware template has all the data, the VM instance also will be populated all the required fields.
- When discovery runs through CMP and it is found that the hardware id associated to a VM has no matching record in cmdb_ci_compute_template table it inserts a new row for that hardware type in cmdb_ci_compute_template by just populating the object_id column with the hardware id as it's value and discovery_source column with value as ServiceNow.
- As a workaround, we can create a row in "cmdb_ci_compute_template" table for the missing hardware id's to make values for these columns to be populated.
- If needed to build up the data cmdb_ci_compute_template table, we can use this behaviour by looking at those Hardware Types records in cmdb_ci_compute_template table for which only column object_id has a valid value and the discovery_source is ServiceNow, they can fetch the configuration for those Hardware Types from AWS and populate the correct values for leftover columns such as vCPUs, Memory MB, Storage GB, name etc. and keep on building the data in cmdb_ci_compute_template table.
- if possible, we can consolidate the data that we wish to put in cmdb_ci_compute_template table for once maybe by contacting AWS or referring to online AWS docs for LDC based supported Hardware Types and then populate the cmdb_ci_compute_template table.
- How to identify if the discovery actually getting all the data and it cannot populate to the fields.
- We can find the ListNode response on Cloud Admin Portal->Operate->Trails->Cloud Orchestration Trail. We can filter on the Method Name column for ListNode and Provider name column for the specific cloud provider, verify the payload contains all the required information if the payload itself has no data the IRE will write the same to the VM instance table.
- Can response mapping solution be implemented as a workaround?
- The payload doesn't have information (Example:vCPUs, Memory). It only has the hardware id for the given hardware type. This information (vCPUs, Memory) comes to the table as a part of the discovery of hardware types which gets stored in "cmdb_ci_cloud_template" table. When LisNodes runs as a part of discovery, it uses the response mapping available for "cmdb_ci_vm_instance" table in "sn_cmp_response_mapping" table and uses the data available in "cmdb_ci_cloud_template" table to populate (vCPUs, Memory). Hardware types currently discovered by CMP are legacy hardware types only.