Loading...
Loading...
The business rule is not updating cmdb_ci_availability_zone to retired because that business rule only checks for records in cmdb_rel_ci table where the logical datacenter is the child, but in the case of the availability zones, the availability zone is the child in the relationship. You can check this execution script history to see that when you have retired the entire account, then logical datacenters were retired, and then resources on those logical datacenters. But the logic in that business rule seems to be flawed as per customer as it assumes that everything that is hosted within the logical datacenter is set as the parent in the cmdb_rel_ci record for resource <> logical datacenter. # Link to the business rule: https://xxxxx.service-now.com/nav_to.do?uri=sys_script.do?sys_id=aac4ea000ba803003503e0d425673aed Steps to Reproduce 1. Customer have their Own project in the Google Cloud Platform (GCP). 2. Within that project, they have a list of regions where you can deploy your resources. 3. Within a given region, Google offers a couple of different sub-regions where you can deploy your resources -- think of them as physical locations/data centers where they (Google) actually have physical servers running in a building with cooling and stuff. 4. Now, when we get rid of a project in GCP, there are two business rule that will sync the update to the install_status from the project down to its resources. But the problem is that records in the cmdb_ci_availability_zone are not being updated by those business rules. 5. Here is a record of cmdb_rel_ci record for availability zone & logical datacenter that shows that the logical datacenter has been retired but not the availability zone: https://xxxx.service-now.com/nav_to.do?uri=cmdb_rel_ci.do?sys_id=b13371a81b9ce8d0b7b8b9d1cd4bcb21 <xml> <cmdb_rel_ci> <child display_value="us-west1-a">xxxxxx</child> <connection_strength>always</connection_strength> <parent display_value="us-west1">xxxxxx</parent> <percent_outage/> <port/> <sys_created_by>xxxx</sys_created_by> <sys_created_on>2020-11-02 11:16:48</sys_created_on> <sys_id>xxxxxxxx</sys_id> <sys_mod_count>0</sys_mod_count> <sys_updated_by>xxxx</sys_updated_by> <sys_updated_on>2020-11-02 11:16:48</sys_updated_on> <type display_value="Contains::Contained by">xxxxxxxx</type> </cmdb_rel_ci> </xml> Workaround 1. The business rules are configured based on status for Cloud Service Account and LDC (the parent table, not the individual cloud vendor child datacenter tables), so the configuration is the same for all Cloud Vendors. 2. if the BR code is checked you would see that they are configured ONLY based on LDC relation direction. Meaning that they will update only CIs where the LDC is the child CI, because of the nature of the Hosted On relationship type. 3. All Cloud Vendor Availability Zones relations is that they are the CHILD of LDC. Attached screenshots for AWS, Azure and GCP proving this point. AWS:- Azure:- GCP:- Conclusion - with points 2 and 3, the conclusion is that the Availability Zones status will NOT be updated for any cloud vendor, not specifically for GCP. Btw if we test this with an AWS account the AZ status for AWS was NOT updated, but this is only logical once you check the settings for all vendors. The solution could be needs to add one further check in the 'Cascade Update LDCs Resource State' BR that will update also resources where the LDC is the parent record in the relation. Basically the existing code can be repeated once more with switched parent-child. Right now this is under investigators with the Development team with this enhancement PRB and will fix this based on the further release informations provided in the PRB. Please subscribe this KB to get further update on this.
PRB1463046
Click on a version to see all relevant bugs
ServiceNow Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.