Bug #3658: When two nodes share the same machine, the deletion of one does not update the container DN of the second - Rudder - Issue Tracker

Custom queries

8.1 beta
Bugs triage
My TR
Need technical review
Open bugs (all)
Open bugs (UI - UX)
Open UX defects (all)
Opened by users

Actions

Copy link

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 11 years ago. Updated over 9 years ago.

Status:

Rejected

Priority:

N/A

Assignee:

François ARMAND

Category:

Web - Nodes & inventories

Target version:

2.6.20

Pull Request:

Severity:

UX impact:

User visibility:

Effort required:

Priority:

Name check:

Fix check:

Regression:

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.

History
Notes
Property changes

Actions

Copy link

Updated by Vincent MEMBRÉ almost 11 years ago

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

Actions

Copy link

Updated by Nicolas CHARLES over 10 years ago

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 ...

Actions

Copy link

Updated by Nicolas CHARLES over 10 years ago

To be more precis, Fabrice regenerated the uuid of a node, accepted the new one and then deleted the old one. Then deployment failed

Actions

Copy link

Updated by Nicolas PERRON over 10 years ago

Target version changed from 2.4.8 to 2.4.9

Actions

Copy link

Updated by François ARMAND over 10 years ago

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)

Actions

Copy link

Updated by Nicolas PERRON over 10 years ago

Target version changed from 2.4.9 to 2.4.10

Actions

Copy link

Updated by Nicolas PERRON over 10 years ago

Target version changed from 2.4.10 to 2.4.11

Actions

Copy link

Updated by Nicolas PERRON over 10 years ago

Target version changed from 2.4.11 to 2.4.12

Actions

Copy link

Updated by Nicolas PERRON over 10 years ago

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 ?

Actions

Copy link

#10