What is `Allow fallback to parent's rules` used for

[pbels1]

In the identification entry there is a field `Allow fallback to parent's rules`.  What is this field used for?

[Cindy Trieu]

My apologies for the late reply! Parent would mean the parent class in the hierarchy. So one use case is if you are trying to identify a Tomcat. A Tomcat is within the hierarchy CMDB CI -> Application -> Application Server -> Tomcat.

Let's say you pass in the Tomcat previously with the right criterion attributes (class is Tomcat, running process commands, a relationship, etc.) Later, a different source reports this same Tomcat, but as a different class and you don't allow this source to downgrade back to Application. The Tomcat will still be discovered just fine because even though you are passing in a different class, it is allowed because you allowed it to "fallback" to the parent rule.

There are other examples as well where the parent doesn't have the same criterion attributes that the child has defined. It would work similarly that if you pass in the identifying criterion attributes for the parent rule, it will still match the same CI because you configured it to allow it to do so.

Hopefully that makes sense! Let me know if you have further questions.

[mbourla]

Hi @Cindy Trieu,

What I don't understand is why "Allow fallback to parent's rules" only applies to "dependent" CI Identifiers (as stated in that Docs page), and not to independent CI Identifiers.  Can you help me with that please?

Thanks
Michael

[Cindy Trieu]

Hi @mbourla ,

Oh yes, here is a good explanation provided by my colleague:

"We don't allow fall back to parent for independent rules as it breaks class switching between classes. If the rules on parent are completely different and if you switch classes you will end up with duplicates. That's the reason we require to define rules at parent level and inherit them to allow class switching."

Class switching for CI items can also cause data loss, so we don't want to arbitrarily allow class switching for independent items to happen easily.

But if you have a use case that can't be done using our product today, please let our PM know through enhancement request. Our PM's are always happen to talk to our customers about how you use our products and what you're looking for!

[mbourla]

Thanks, @Cindy Trieu.  To be honest, I'm not really following all this 😕. 

Something else I've never got is why that "Allow fallback to parent's rules" checkbox is on individual Identifier Entries.  I would have thought it would be on the overall CI Identifier.  Especially because when it says "parent's rules", the rules must mean the Identifier Entries on the CI Identifier.  Which to me implies it should exist on the CI Identifier, not on any individual Identifier Entries.  Otherwise is it saying that when it's processing the possibly many Identifier Entries on a given CI Identifier, in Priority order, if it tries one and doesn't find a match but "Allow fallback to parent's rules" is true, it abandons the remaining Identifier Entries, and instead restarts using the parent class's CI Identifier?

I can see that in the OOTB CI Identifiers, there *are* quite a few Identifier Entries with "Allow fallback to parent's rules" checked.  If someone can give a concrete example of IRE being used for identification, with "Allow fallback to parent's rules" checkbox being true and how it affected the identification logic, that would be really useful.

Regards

Michael

[Cindy Trieu]

These are all good points Michael. This feedback is very valuable to our team, especially our PM. If you would like a longer conversation, you should look into arranging a meeting with our PM, Navin Sharma, and talk to him at length about the confusion of fallback rules, why they don't apply to independent rules and your perspective on how it should work.

Unfortunately I don't have the reason for why it works like this today, but I am happy to help you with any issues you do encounter while setting them up or with IRE ingestion.