The aging reports are often hard to read, not monitored properly and aging may delete large chunks of data. Working with several UCMDBs I often need to see what has been deleted by enrichments or by mistake and eventually to undelete the deleted Cis. I would love to have the option to see what has been deleted in more detail that the Audit Report available in Custom Reports section, as well as eventually to undelete the CI and relationships in question.
FWIW, probe side caching issues have bit me over the years, causing unexpected CI delete/recreates. And depending on integration logic and downstream tools... changing a UUID may cause significant pain.
Depending on the backend database flow... it could be straightforward to get a handle on the full cascaded/related dataset prior to the delete. If not, can I suggest a best guess via a dynamic query operation to get a handle on the things that would be touched or removed? And then take that map dataset and throw it out to a data lake (simple delete/insert operation - tagged by the root_id)... Vertica is a good choice.
If the architecture is bolstered by a data lake option for deletes... the next logical step to use it for all CIs and change history, and not just deleted ones. That would definitely expand the functionality available to History tracking.
IMHO, this should exist for both manual and aged CI's. My thought process is that if an agent stops responding and we don't catch it, the CI is deleted. We've had this happen on multiple devices over the years, and I believe that until improved agent communication and visibility is implemented, this will be an ongoing issue... but that's a conversation for another thread.
I would agree also that you would have to include the deleted CI, it's immediate relationships, all CIs that would be deleted in the "cascade" effect of the Composition relationships and the immediate relationships of those cascaded CIs. Perhaps make recovery a scheduled action so we can time it after hours if it is intensive?
I guess the real point I want to make is that for the enhancement forum to be successful, your clients need to know that popular enhancement requests are going to make it into the development cycle. If this thread status was updated to say "targeted for 2020 Q4 delivery" instead of "under consideration" I would've never commented. I respect that the Microfocus team is busy with core development, but we'd like to see enhancements co-exist with product development. Maybe consider updating top requests with target implementation dates so that both sides play nice?
Last year we had a case where a uCMDB user inadvertently deleted 16 Nodes because he thought that he had selected 16 relationships to those nodes but had also selected the nodes themselves. Each node had about 2000 objects connected to it with Composition relationships (InstalledSoftware, Running softwares, Node elements, etc.). So a single delete operation had effectively deleted about 32,000 objects and as many relationships. It took us about 10 days to restore everything because we had to wait for 2-3 discovery cycles to run. Then, restoring the manual relationships that were created between Application CIs and the nodes/running softwares was a pain because all re-discovered objects had new Global IDs.
So, yes, recycle bin would only apply to manual deletion as aging, with the concept of "candidate for deletion", already gives a warning of a pending automatic deletion.
With our experience, I think that the recycle bin would have to include the deleted CI, it's immediate relationships, all CIs that would be deleted in the "cascade" effect of the Composition relationships and the immediate relationships of those cascaded CIs. I agree, that can mean a lot of CIs!
Sometimes, implementing a feature like that is as simple as adding a "deletion date" special attribute to the CIs and relationships. By default, only items with a NULL deletion date would be displayed. Someone with a special privilege would then be able to enable "Show deleted CIs" in his session to make them visible and be able to undelete them. Just like with aging, deleted CIs would be physically removed from the database after a specified number of days. Of course, even if the CIs in the recycle bin are technically present, they would not be processed to be merged with non-deleted CIs.
Currently, in order to compensate for a lack of recycle bin, we make a daily backup of all the manual relationships in order to be able to restore them in case an unwanted deletion occurs. It is not a perfect recovery solution, but it saved our a** a couple times in the past.
We agree this would be a very useful feature. However, the timing is tough because we would want to implement this as part of the CMS UI improvements and not in the Admin UI (as that is wasted effort for us). Our focus on the CMS UI is still in getting the core Admin UI capabilities added to the product, such as adding the ability for folding and grouping of reports, a useful textual-based reporting UI, native CMS UI capabilities for properties, topology and impact widgets, and a useful "get related" capability.
When we have those capabilities in the CMS UI, the recycle bin becomes high on our priority list.
When you think of a recycle bin, what use cases come to mind? Our first thought was only for the use case of manual deletion of a CI, as a CI that was aged out should NOT be allowed to be restored.
Additionally, when you architect a recycle bin solution within the context of UCMDB, how far do you take it? If you accidentally delete a node, a LOT of other data is deleted as well. Do you allow for recovery of ALL the related CIs and relationships? That will consume a lot of memory in situations where a CI (or multiple) are deleted. Anyways, these are the thoughts we've already kicked around on this concept as we have considered it for implementation.