Relationship Conflicts for Scheduled Changes

[Legacy User]

Is it possible to easily determine conflicts between scheduled Change Orders (CO) when selected Configuration Items (CI) have relationship conflicts as opposed to conflicts with the CI's? As an example, if CI ServerA is associated with multiple scheduled CO's we will see the conflict. We want to see the conflict if AppB is running on ServerA and ServerA is in one CO and AppB is in a different one.

[Anon Anon]

I do not believe that this exists out of the box because of its recursive nature - since you can have an infinite number of relationship levels it would cause performance issues.  To do this efficiently you would need a table that related each CI to each other CI in the relationship dependency tree, and that would require some significant customization.  You could also design some advanced reporting to perform the same task, but I do not think either of these solutions would fit your definition of "easy".

 

Your final solution would be to manually (or via custom spel code) attach all dependent CIs to a change order involving one CI.  This would allow OOTB conflict monitoring.  I have never seen this done, but perhaps someone else has had this same idea and done something similar?  Hopefully this gives you something to go on!

 

Regards,

 

Marty

[Lindsay_Estabrooks]

It would appear to me that the person creating the Change Order for AppB is failing to include the server(s) that are being updated as part of the list of CIs that are being touched by the Change Order.

 

If I have a Change Order for ServerA (for example, to apply OS patches) then ServerA should be listed as one of the CIs for that Change Order. If I also have a Change Order for AppB that runs on ServerA then I should list both AppB and ServerA as CIs on that Change Order.

[Legacy User]

Therein lies the problem we are trying to resolve with the tool. In your example you know that ServerA hosts AppB and that is not always the case in our environment. The relationship between ServerA and AppB is defined in the CMDB, which is why we want to the tool to notify us of potential conflicts. It seems like if the relationships exist, then I shouldn’t have to include each CI related to the primary CI on the CO. It sounds like the tool can’t do this for various reasons so we will look at other options.