auto delete option in ucmdb doesnt work if job is deactivated in between discovery cycles

Idea ID 2768831

auto delete option in ucmdb doesnt work if job is deactivated in between discovery cycles

At present the ucmdb discovery option "Auto Delete" option doesn't work or not effective when deactivation of the discovery job is done between two discovery cycles. At present AutoDelete option works on the basis of the difference of result between two discovery cycles. As deactivation removes the old discovery results from the probe database and hence this option doesn't work. It is not good design and not reliable as part of administration purpose or troubleshooting purpose many times, the job gets deactivated.

12 Comments
Trusted Contributor.. Trusted Contributor..
Trusted Contributor..

Hello, thanks for raising this idea on my behalf. This originially came from a support case (SD02635345) where I just noticed this behaviour and thought it must be an issue. For example, if a CPU is removed from a server or software is uninstalled, this MUST be reflected in uCMDB even if the discovery jobs have been restarted in between two scan runs! Otherwise essential processes which we support by uCMDB in our company cannot work reliably and we would have to evaluate different tools which might support this better. This is not a nice-to-have but MUST-HAVE feature for us! Thank you for your understanding!

Micro Focus Expert
Micro Focus Expert

hi,

I fully understand your use case and definitely it should be implemented.

however, independently from the auto deletion feature I would rather take the "last access / discovery time" to know which CPU or installed software still belongs to a node.

best regards

daniel

Acclaimed Contributor.
Acclaimed Contributor.

There is a danger that the implementation of such a rule will cause more trouble that bring benefits. It has to be well documented that AutoDelete counts on the cache of the DFP and that if the cache is cleared, the AutoDelete will not function. Cache can be cleared by manual action from the menu of the job or by deactivating the job. If you don't want the cache to be cleared, don't deactivate the job. 

If you stop clearing the cache, there will be other issues appearing - mass deletion of CIs when some job option gets reconfigured. Also you cannot really count 100% of the Autodeletion working because:

1. Very few customers think that DFP database is essential and they don't back it up

2. DFP may get upgraded or changed

3. IP Address assignment may be changed if you use several DFPs into cluster. 

 

Therefore a bad design of your essential processes shouldn't be tackled in product change, but by creating another "deletion process". It will take you just a small enrichment rule based on the last access time of the CPUs attached to a server to easily detect when some of the CPUs have "Last Access Time" changed, while others stay the same. You can safely delete the old CPUs. 

Trusted Contributor.. Trusted Contributor..
Trusted Contributor..

Thanks for all the replies. I have understood now how AutoDelete works. Maybe the fact that it only works if the probes are not restarted and cache is not cleared should be more pointed to in the documentation. Or maybe because it works the way it works, one should consider to completely remove the whole feature.

And please don't tell me that my processes are badly designed if in reality a feature of the product does not work as someone with normal perception would think. Thank you.

Super Contributor.
Super Contributor.

I fully agree with thomas_eee and b_bravi.

We use Universal Discovery and the UCMDB for hardware and software inventory. Nobody told us, that there are restrictions when you stop jobs or clear the cache.
It is nowhere to be found in the documentation in this clarity.
For other jobs, such as Inventory Discovery by Manual Scanner, the auto-delete mechanism doesn't work at all.
We can't do a correct inventory, if we count wrong numbers for software etc.
That is intolerable for such a product. I am surprised that other customers simply accept this problem.

Acclaimed Contributor.
Acclaimed Contributor.

first to be clear - the feature works if you take into account several things - no reinstalls, no disabling of the jobs and no clearing of the cache or changing the probe assignment of IPAddresses. Restarts of the service are permitted, since they don't clear the cache. 

This feature is supporting of the aging and it works in most cases. @AMensching it does work for Inventory, you have to debug why it doesn't work for you. 

Yes, I agree - documentation should be more clear on this feature! I've spent months to find all the issues of the auto-delete and after few tickets to support and patch execution it started working for integrations as well. 

@thomas_eee it is not bad design on your side to expect something to work as documented. But it is bad design when it doesn't  work as you expect and instead of changing your processes, you insist for software changes. My opinion is that such changes will break more things than they will fix. All your troubles can be fixed with a small enrichment executed once per day. 

I have no trouble with this feature working as it is, because I consider it as supporting functionality to the aging. It works in 90% of the cases and the other 10% are cleared either by aging, or, if it is time-critical, by enrichment.

Super Contributor.
Super Contributor.

@popadiyski: Auto-delete does not work for the Inventory Discovery by Manual Scanner job per design. This has already been confirmed for that job by the Micro Focus support. That's a fact.

For the other jobs, the documentation should be optimized, so that the functionality and effects of the probe cache can be understood for everyone.

Otherwise we need at least current inventory data and no data that may only be corrected by the aging process or manual enrichments.

Acclaimed Contributor.
Acclaimed Contributor.

@AMenschingwhy are aging and enrichments not a solution for you? What does "current inventory data" mean for you?

UCMDB is made to merge numerous sources of data. We run 4-5 different jobs to create the full CI model picture. Every job is contributing with different perspective of it. Therefore we can't say that Inventory scanning knows it all and what is not provided by it, should be removed. I can't see one single solution for all the CMDB customers in the world. 

Therefore the aging and enrichments come into picture for specific requirements like the one described by Thomas. The default aging takes 40 days, which is ok for me. If you discover all your servers each week, then make the 10 days for the CPUs. If not, compare the last access time of all the CPUs of the server and delete the one discovered earlier. Is that simple. No need to change the UCMDB software, since it is flexible to implement these solutions. 

If you want auto deletions implemented for Inventory Discovery by Manual Scanner, then investigate the ways to do this. The caching process is general for all jobs and integrations. I am really surprised that it is not available for Manual Inventory. Is there a technical reason to prevent you to go to 
InventoryDiscoveryByManualScannerDeployment adapter, enable the adapter configuration for "Automatic Deletion" and set which CI types to be included in the list of deletions? Or the support responded that by default the auto deletion is not enabled for Manual Inventory?  From what I see the automatic "touching" based on the cache is enabled. Therefore the cache contains all the data necessary for the auto-deletion to work. 

 

Super Contributor.
Super Contributor.

Hello @popadiyski ,

the auto-delete functionality is not configured for the "Inventory Discovery by Manual Scanner" job,  because the design of the job cannot provide it. This is a limitation of the product, that we were not aware of before.

Just accept that it doesn't work, or do you know more than the manufacturer?

What I mean by current inventory is, that after a scan I recorded exactly all hardware and software components. This should be possible at any time after each scan (regardless of whether I have stopped a job in between or cleared the cache). The product must be able to do that OOTB and I no longer have to create and start manual enrichments. Aging should also not be necessary for this.

Every customer has different requirements of a CMDB. One of our requirements is a correct preliminary inventory and Universal Discovery and the UCMDB are currently not fully able to do this.

Acclaimed Contributor.
Acclaimed Contributor.

@AMensching I don't argue with the vendor's statement. I argue with the statement made by an anonymous user in a forum in Internet, which contradicts the logic of the product.

And I am not talking blindly, just for the sake of the argument! I've made a small test - I've enabled the auto deletion for CPUs. I've put "Candidate for Deletion" method in order the CIs not to disappear but just get marked as candidates:

adapter_autodelete.PNG

Then I've sent a manual inventory scanner with 4 CPUs inside to create the CI. Then I removed 2 CPUs from the scan file and sent it again. Here is the result of AutoDelete working for Inventory by Manual Scanner:

cpu_autodelete.PNG

 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.