- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-12-2023 04:32 AM
Hi all, first of all thank you for opening the post.
I was working on a feature for Linux Server OOB pattern (DEV instance) in order to add a customized step for OVM Virtual Machines discovery, which is not implemented in the default OOB pattern.
So I created a shared library and added it into the Extension Section (I did not modify the main "discovery" pattern in the Identification Section) but while testing the entire Linux Server pattern it gave me a "Identification Engine: Discovery status is FAILURE, Identification sections in pattern failed: section: discovery, error: Relation and/or reference table xxx is not a known CI Type." kind of error, from a step in the custom extension.
So I changed some steps in the extension, but it gave still the same error.
Searching here in the community I found different posts that suggested to always sync with mid servers when doing edits in the patterns in order to be sure that mid server is running the latest version of that pattern. So I did it by selecting the pattern in the table > Actions on selected rows lookup > Synchronize with MID Servers. After that, returning in the Linux Server pattern, all extensions disappeared, both the one created by me and those already there, and running the pattern started giving the error "Relation and/or reference table cmdb_fc_initiator is not a known CI Type. Check the discovery logs for more details." from the main discovery pattern, even though I absolutely did not changed anything in that pattern nor in the other OOB shared libraries. I only worked in the extension I created by myself.
I tried synchronize it again, putting back the extensions manually, but nothing worked, still the same error.
Is there a way to install back the OOB version of the pattern? Or do you have other solutions for this problem?
Just to be clear, I'm working only in DEV instance. Pattern in PROD instance is still working fine.
Thank you very much for your help.
Solved! Go to Solution.
- Labels:
-
Discovery
-
Orchestration (ITOM)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-17-2023 07:03 AM
Okay, I've leave it there for others to see.
I found a solution, the pattern was not corrupted but just switched to another domain that was not global. Without noticing, I've synched with MidServer while being in another domain, so another copy of that pattern created in this local domain, that could not reach global variables and gave me that error. Deleting local copy and switching back to global domain solved everything.
Thank you for your help!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-13-2023 02:28 AM
Hi @Au_an
No, not this one, the linux server pattern is part of platform release, this plugin which you mentioned has different patterns and this is available from SNOW Store.
So for the linux server pattern you need to repair the platform plugin which I mentioned in my previous post.
You can check with your relevant team to find out the exact plugin name for discovery that was installed on your instance.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-17-2023 07:03 AM
Okay, I've leave it there for others to see.
I found a solution, the pattern was not corrupted but just switched to another domain that was not global. Without noticing, I've synched with MidServer while being in another domain, so another copy of that pattern created in this local domain, that could not reach global variables and gave me that error. Deleting local copy and switching back to global domain solved everything.
Thank you for your help!