Project

General

Profile

Actions

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É over 11 years ago. Updated almost 10 years ago.

Status:
Rejected
Priority:
N/A
Category:
Web - Nodes & inventories
Target version:
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.

Actions #1

Updated by Vincent MEMBRÉ over 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 #2

Updated by Nicolas CHARLES over 11 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 #3

Updated by Nicolas CHARLES over 11 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 #4

Updated by Nicolas PERRON over 11 years ago

  • Target version changed from 2.4.8 to 2.4.9
Actions #5

Updated by François ARMAND over 11 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 #6

Updated by Nicolas PERRON about 11 years ago

  • Target version changed from 2.4.9 to 2.4.10
Actions #7

Updated by Nicolas PERRON about 11 years ago

  • Target version changed from 2.4.10 to 2.4.11
Actions #8

Updated by Nicolas PERRON about 11 years ago

  • Target version changed from 2.4.11 to 2.4.12
Actions #9

Updated by Nicolas PERRON about 11 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 #10

Updated by Nicolas PERRON about 11 years ago

  • Status changed from New to Discussion
Actions #11

Updated by Nicolas PERRON about 11 years ago

  • Target version changed from 2.4.12 to 2.4.13
Actions #12

Updated by Vincent MEMBRÉ almost 11 years ago

  • Target version changed from 2.4.13 to 2.6.11

Since 2.4 is not maintained anymore, retargeting to branch 2.6

Actions #13

Updated by Vincent MEMBRÉ almost 11 years ago

  • Target version changed from 2.6.11 to 2.6.12
Actions #14

Updated by Vincent MEMBRÉ almost 11 years ago

  • Target version changed from 2.6.12 to 2.6.13
Actions #15

Updated by Vincent MEMBRÉ over 10 years ago

  • Target version changed from 2.6.13 to 2.6.14
Actions #16

Updated by Jonathan CLARKE over 10 years ago

  • Target version changed from 2.6.14 to 2.6.16
Actions #17

Updated by Jonathan CLARKE over 10 years ago

  • Target version changed from 2.6.16 to 2.6.17
Actions #18

Updated by Nicolas PERRON over 10 years ago

  • Target version changed from 2.6.17 to 2.6.18
Actions #19

Updated by Matthieu CERDA about 10 years ago

  • Target version changed from 2.6.18 to 2.6.19
Actions #20

Updated by Vincent MEMBRÉ about 10 years ago

  • Target version changed from 2.6.19 to 2.6.20
Actions #21

Updated by François ARMAND almost 10 years ago

  • Status changed from Discussion to Rejected

It is no more present in 2.10

Actions

Also available in: Atom PDF