Exclude CI not to be discovered in Cloud discovery specially in azure discovery

[Insomaniac]

in cloud discovery can we exclude some CI which we don't want the discovery to discover specially the Azure discovery

[SiD2]

Hi @Marek Meres 

It's difficult to see at once as it's a hierarchical configuration; you need to see for which pattern the parent pattern is configured to "Hardware Type" pattern in the "Pattern Orchestrator" tab when you open the pattern in pattern designer.

Btw I would like to know why you don't want to discover some CIs, as it is not highly recommended. As these are LP patterns and hierarchical, if you turn off the root patterns, you may discover nothing like in your example.

You can turn off the Inventory pattern on the second query, and no CIs will be discovered.

[Marek Meres]

Hi @SiD2 ,

Thanks again! So basically I need to go through all (or maybe just '4 - Cloud Resource') patterns and see on the "Pattern Orchestrator" tab if "Azure - Hardware Type (LP)" appears on any of them (similarly to "Azure Datacenter discovery" appears as parent on the "Azure - Hardware Type (LP)").

Regarding excluding certain discoverable resources this is partially customer's preference (cmdb_ci_cmp_resource) and partially temporary decision to investigate cloud discovery in more details (cmdb_ci_compute_template). We got many duplicates after the first run but as this was run in parallel with SGC for Azure this might have been the culprit. So we decided to delete what was discovered and the major part of CIs for deletion were 0.5 million of "cmdb_ci_compute_template" CIs. Hence we want to disable them at least for now.

Btw: I am familiar with horizontal discovery patterns and how they are triggered from Classifiers, have some knowledge about top-down patterns but I do not know much about Pattern Orchestrator and how it works. I am pretty sure it was not in the Discovery course (I did this a few times) and the documentation page is very sparse. Is there a good source to learn more about how this pattern orchestration works (for instance simply knowing which table the parent-child orchestration relationships are stored would simplify searching for dependent patterns a lot (I thought first this is sa_pattern.parent but this is NULL for all patterns)). Many thanks in advance!

[SiD2]

Hi @Marek Meres 

Yes, you got that right. I'm also unaware if any doc exists but will share if I find out any.

However, it's a simple configuration where the parent pattern should be executed in order to execute child patterns. The orchestrator inputs are the data i.e. passed by the parent pattern on which you would see the same inputs defined as Orchestrator outputs. The service account validation always executes first and then followed a subaccount pattern if applicable and followed by data center discovery. Further from here, the orchestrator config follows as to which pattern needs to execute thereafter.

You can check below tables:

Pattern Trigger Rule - sn_pattern_trigger_rule

Pattern Orchestrator Inputs - discovery_ptrn_lnch_param_def_ext

Pattern Orchestrator Outputs - sn_discovery_orchestrator_pattern_output

I understood about disabling part, yes you can disable independent patterns like inventory but orchestrator patterns are not recommended due to their execution nature as all child executions are interrupted.

Hope this helps!

[Marek Meres]

Hi @SiD2 

Many thanks again! You saved me a lot of clicking and doubting with your clarifications and by giving the Pattern Trigger Rule table name! Filtering this on "Parent Pattern" ="Azure - Hardware Type (LP)" I have easily found that "Azure - Virtual Machine (LP)" depends on it! So unfortunately I cannot switch it off as I would forfeit the VM discovery...

Unfortunately I cannot mark any of your excellent answers as "correct answer" as the thread was not mine but I am very grateful for your time and expertise shared! Many, many thanks and best regards!

Marek

[SiD2]

@Marek Meres , Anytime 🙂