Bug #3658
closed
When two nodes share the same machine, the deletion of one does not update the container DN of the second
Added by Vincent MEMBRÉ almost 12 years ago.
Updated about 10 years ago.
Category:
Web - Nodes & inventories
Description
I had a node created with KVM and rudder-agent installed on it.
I clone this machine, and change UUID of both nodes (so they have both different NodeId)
I accept both in Rudder and have 2 separated nodes.
Then i delete the first node, and the deployment is in error
It says that : container of the second node could not be found.
I supose that they share the same machine ID and when first node was deleted, the machine inventory was send to removed inventories, but the second node is still pointing to accepted inventories, but there is no inventory anymore
- Category set to Web - Nodes & inventories
- Target version set to 2.4.8
Fabrice had this issue
He told us that the deleted node id was still in the group with nodeGroupId: hasPolicyServer-root
There is something fishy there ...
To be more precis, Fabrice regenerated the uuid of a node, accepted the new one and then deleted the old one. Then deployment failed
- Target version changed from 2.4.8 to 2.4.9
- Subject changed from When there is two node based on the same machine (kvm clone), deleting one result in deployment error to When two nodes share the same machine, the deletion of one does not update the container DN of the second
It should be linked to #3887
That seems to happen is that when a node is deleted, it's machine is moved to the "deleted node" even if other nodes have that machine as container.
So, we have to either don't change the machine container (but that means that when we do delete a node and it's the last one, we have to also change deleted node container), or change the machine container, but check if other nodes also need to be change.
Perhaps a better long term solution would be to have only one inventory branch, and manage node status in the node branch, so that "purging" old inventories is a self contained method, not linked to acceptation/deletion, more easely testable (see #3903)
- Target version changed from 2.4.9 to 2.4.10
- Target version changed from 2.4.10 to 2.4.11
- Target version changed from 2.4.11 to 2.4.12
- Assignee set to François ARMAND
François ARMAND wrote:
It should be linked to #3887
That seems to happen is that when a node is deleted, it's machine is moved to the "deleted node" even if other nodes have that machine as container.
So, we have to either don't change the machine container (but that means that when we do delete a node and it's the last one, we have to also change deleted node container), or change the machine container, but check if other nodes also need to be change.
Perhaps a better long term solution would be to have only one inventory branch, and manage node status in the node branch, so that "purging" old inventories is a self contained method, not linked to acceptation/deletion, more easely testable (see #3903)
Not sure to understand the fix of #3887 then I don't know if it could have an effect on this issue. What's you opinion about it, François ?
- Status changed from New to Discussion
- Target version changed from 2.4.12 to 2.4.13
- Target version changed from 2.4.13 to 2.6.11
Since 2.4 is not maintained anymore, retargeting to branch 2.6
- Target version changed from 2.6.11 to 2.6.12
- Target version changed from 2.6.12 to 2.6.13
- Target version changed from 2.6.13 to 2.6.14
- Target version changed from 2.6.14 to 2.6.16
- Target version changed from 2.6.16 to 2.6.17
- Target version changed from 2.6.17 to 2.6.18
- Target version changed from 2.6.18 to 2.6.19
- Target version changed from 2.6.19 to 2.6.20
- Status changed from Discussion to Rejected
It is no more present in 2.10
Also available in: Atom
PDF
Updated by 
Updated by Nicolas CHARLES over 11 years ago
Updated by Nicolas PERRON 
Updated by François ARMAND over 11 years ago
Updated by Jonathan CLARKE 
Updated by Matthieu CERDA