User story #2094
closed
When we remove a Node from Rudder, save its information in a "Removed inventories" branch of LDAP
Description
Should we move the inventory in another LDAP branch, like "Removed Inventories" ?
Should we delete reports ?(I don't think so)
In a word, what should happen ?
Updated by Jonathan CLARKE almost 13 years ago
- Target version changed from 2.4.0~alpha2 to 2.4.0~alpha3
Updated by Jonathan CLARKE almost 13 years ago
- Target version changed from 2.4.0~alpha3 to 2.4.0~alpha4
Updated by Jonathan CLARKE almost 13 years ago
- Assignee changed from Jonathan CLARKE to Nicolas CHARLES
- Priority changed from N/A to 2
No, we should definitely not delete reports!
I favour moving the node inventory into another branch, like "Removed inventories". This way, if the node ever comes back (was only removed temporarily, or user made a mistake deleting it), we'll be able to restore it easily.
What needs to be done to achieve this?
Updated by Nicolas CHARLES almost 13 years ago
Currently, the Node is deleted, but the reports remains (has well as all historizations)
To move it to another branch, we need to :- Create the Branch
- Modify the deletion service to move the inventory to this branch rather than deleting it
- Modify the accept inventory service to look for deleted inventories, and restore a matching deleted inventory
- Have some clever part that would solve possible conflict (for instance, if the inventory is not completely the same as before)
- Figure if we should also save the inclusion in static groups (with the same issue has previous point, if the node is really deleted or just a mistake)
Updated by Jonathan CLARKE almost 13 years ago
- Tracker changed from Question to User story
- Subject changed from When we remove a Node from Rudder, what should happen of all its information ? to When we remove a Node from Rudder, save its information in a "Removed inventories" branch of LDAP
- Category changed from Architecture - Code maintenance to Web - Nodes & inventories
- Assignee deleted (
Nicolas CHARLES) - Target version changed from 2.4.0~alpha4 to 2.4.0~alpha5
As discussed this morning, we can't address this in the current run, retargeting for alpha5.
I think the first step should be your points 1 & 2 above, to at least make sure we don't completely remove the data. Handling restoration and conflict resolution would be great, too, but could be done later, and benefit from the "saved" data on existing instances.
Updated by Jonathan CLARKE almost 13 years ago
- Target version changed from 2.4.0~alpha5 to 2.4.0~alpha6
Updated by Jonathan CLARKE over 12 years ago
- Target version changed from 2.4.0~alpha6 to 2.4.0~alpha7
Updated by Nicolas CHARLES over 12 years ago
- Status changed from New to 8
- Assignee set to Nicolas CHARLES
- Estimated time set to 10.00 h
I'm starting the point 1 & 2, which should also magically solve the #2093 as a side effect (if I understand what I'm doing)
The following steps will be done :
- Create the branch "Removed inventories"
- update the Inventory api (or find where it is) to have for a given MachineId all the attached NodeId in a DIT
- change all call to the delete so that it will rather be move or copy or nothing (if I can refere to an inventory from the accepted branch)
Updated by Nicolas CHARLES over 12 years ago
- Status changed from 8 to In progress
I created a new branch in the DIT, Removed Inventories, and when a machine is deleted, now it is rather moved to the Removed Inventories branch
Updated by Nicolas CHARLES over 12 years ago
- Status changed from In progress to Pending technical review
Updated by François ARMAND over 12 years ago
- Status changed from Pending technical review to 10
Technical review OK, really nice patch to read, thanks !
Updated by Jonathan CLARKE over 12 years ago
- Status changed from 10 to Released