Bug #16198: When switching a node managed by the root server to a relay, its policies are not regenerated - Rudder - Issue Tracker

Actions

Copy link

Bug #16198

open

When switching a node managed by the root server to a relay, its policies are not regenerated

Added by Félix DALLIDET about 5 years ago. Updated 6 months ago.

Status:

New

Priority:

N/A

Assignee:

Category:

Web - Config management

Target version:

7.3.17

Pull Request:

Severity:

Minor - inconvenience | misleading | easy workaround

UX impact:

User visibility:

Operational - other Techniques | Rudder settings | Plugins

Effort required:

Very large

Priority:

Name check:

To do

Fix check:

To do

Regression:

Description

I had a Windows node managed by my root server, I switched it under a relay, trigger inventory run, triggers, relay/root runs.
But the policies of the nodes where not regenerated under the relay ones in the /var/rudder/share of the root server.

I had to trigger manually a policy generation, which ended up with some duplicated policies:

/var/rudder/share# find . | grep zip
./b8dcd41d-be6f-40e5-9b4f-f494fdeda113/share/3d478f22-a138-4973-bb1d-9a36132b63e8/rules/dsc/rudder.zip
./3d478f22-a138-4973-bb1d-9a36132b63e8/rules/dsc/rudder.zip

Related issues 1 (0 open — 1 closed)

Actions

Copy link

Updated by Vincent MEMBRÉ about 5 years ago

Target version changed from 5.0.15 to 5.0.16

Actions

Copy link

Updated by Alexis Mousset almost 5 years ago

Target version changed from 5.0.16 to 5.0.17

Actions

Copy link

Updated by François ARMAND almost 5 years ago

It should be taken care of with the next dynamic group update. So it is not "more" broken than it ever was.

The correct, long term solution is:

- we have the full graph (hopefully tree ?) of dependencies in all configuration elements, and in particular we have the reverse dependency from groups to node parameters on which they depends,
- we also have a list of special node properties that are always observed (like policy server),
- when an inventory is updated, we have the exhaustive list of changes compared to previous inventory state,
- with that list and the reverse dependencies, we exactly know what groups/policies were updated and so if a policy generation is needed.

The incorrect, but perhaps more affordable solution:
- make generation node by node. When an inventory arrives, start generation for that node only (and it will check if anything relevant changed).

Actions

Copy link

Updated by Vincent MEMBRÉ over 4 years ago

Target version changed from 5.0.17 to 5.0.18

Actions

Copy link

Updated by Félix DALLIDET over 4 years ago

Related to Bug #16741: Policies do not seem to be regenerated when a node change its policy server added

Actions

Copy link

Updated by Félix DALLIDET over 4 years ago

Severity set to Minor - inconvenience | misleading | easy workaround
User visibility set to Operational - other Techniques | Rudder settings | Plugins
Effort required set to Very large
Priority changed from 0 to -11