Project

General

Profile

Actions

Bug #1411

closed

Node (hostname,policyserver,...) modification should trigger promises regeneration

Added by Jonathan CLARKE over 11 years ago. Updated about 5 years ago.

Status:
Released
Priority:
2
Category:
Web - Nodes & inventories
Target version:
Severity:
Major - prevents use of part of Rudder | no simple workaround
UX impact:
User visibility:
Operational - other Techniques | Technique editor | Rudder settings
Effort required:
Priority:
52
Regression:

Description

If a node changes hostnames, we must update the authorization rules in cf-servd.cf. This means a promise regeneration run should be started when the inventory detects a hostname change.

In a more general way, any important change in an inventory must trigger and generation.

Important changes are defined by:
- the property may be used in directives with ${rudder.node....}
- the property is used in a system variable.

The second set should be containt in the first, at least for now, but we should be able to define a more future-proof solution than just enumerating the relevant properties.


Related issues 2 (0 open2 closed)

Related to Rudder - Bug #5316: If policy server hostname changes, the generated promises never take into account the new valueRejectedActions
Has duplicate Rudder - Bug #8046: Change of Policy Server does not trigger a PolicyupdateRejectedFrançois ARMAND2016-03-08Actions
Actions #1

Updated by Jonathan CLARKE over 11 years ago

  • Target version changed from 15 to 16
Actions #2

Updated by Jonathan CLARKE over 11 years ago

  • Target version changed from 16 to 19
Actions #3

Updated by François ARMAND over 11 years ago

  • Assignee set to François ARMAND
  • Priority changed from 3 to 2
Actions #4

Updated by François ARMAND over 11 years ago

That a big thing: we have to:

  • detect inventory updates on a node and trigger other updates (today, we just save the new inventory, without looking for change, and without any callback system - and it's hard to implement, because the two things are not on the same soft, inventory update is in ldap-inventory, callbacks have to be triggered in rudder-web)
  • on some modification (hostname, perhaps IP and other things), trigger a deployment. That's easy if we have to callback system in place.

That was the kind of I wish to do with syncrepl.

For now, I have just no other ideas.

Actions #5

Updated by Jonathan CLARKE over 11 years ago

François ARMAND wrote:

That a big thing: we have to:

  • detect inventory updates on a node and trigger other updates (today, we just save the new inventory, without looking for change, and without any callback system - and it's hard to implement, because the two things are not on the same soft, inventory update is in ldap-inventory, callbacks have to be triggered in rudder-web)
  • on some modification (hostname, perhaps IP and other things), trigger a deployment. That's easy if we have to callback system in place.

That was the kind of I wish to do with syncrepl.

For now, I have just no other ideas.

I thought this might be the answer :-)

How does the "cron" service that updates dynamic groups fit into this? I assume it regularly checks the contents of inventories, and launches "actions" as a result. Could it not be adapted to trigger a redeployment if a hostname was noticed to have changed?

Actions #6

Updated by Jonathan CLARKE over 11 years ago

  • Status changed from 2 to Discussion
Actions #7

Updated by François ARMAND over 11 years ago

Jonathan CLARKE wrote:

How does the "cron" service that updates dynamic groups fit into this? I assume it regularly checks the contents of inventories, and launches "actions" as a result. Could it not be adapted to trigger a redeployment if a hostname was noticed to have changed?

Well, the hard part is "notice that hostname changed". For dyngroup, we use a brut force approach (re-calculate the result of the query, save the change (and the LDAP framework manage the diff-update). That method can't work for hostname, because we want to do something when we save the new hostname, the sole instant when we can check if there is a diff, and that's in LDAP-inventory module.

Perhaps with something with a last-update time and a brut-force approach on a given set of attribute, something like: periodically, look if last-update time in inventory node more recent than last-update time of node, and true, for attribute "hostname, ip, etc" do some-trigger.

Actions #8

Updated by Jonathan CLARKE over 11 years ago

  • Target version changed from 19 to 21
Actions #9

Updated by Jonathan CLARKE over 11 years ago

  • Target version changed from 21 to 23
Actions #10

Updated by Jonathan CLARKE over 11 years ago

  • Target version changed from 23 to 18

Let's work on this for 2.4. This isn't a very common scenario, and there is a simple workaround: click on the "Generate" button.

Actions #11

Updated by François ARMAND over 11 years ago

  • Assignee deleted (François ARMAND)
Actions #12

Updated by François ARMAND about 11 years ago

  • Target version changed from 18 to 24
Actions #13

Updated by François ARMAND about 11 years ago

  • Status changed from Discussion to 8
  • Assignee set to François ARMAND
  • Target version changed from 24 to 2.4.0~alpha3

This was discussed again, and we are thinking it's really important.

Let's do it in the inventory endpoint side. That's bad, we should be able to have a kind of event bus between our app for that, but its a first step.

Actions #14

Updated by François ARMAND about 11 years ago

So, the previous message is only to handle hostname update in the "node" part.

That won't regenerate promises automatically, but the next time a deployment is initiated, the hostname change will be taken into account.

Actions #15

Updated by Jonathan CLARKE about 11 years ago

François ARMAND wrote:

So, the previous message is only to handle hostname update in the "node" part.

That won't regenerate promises automatically, but the next time a deployment is initiated, the hostname change will be taken into account.

That would be a great first step!

Actions #16

Updated by François ARMAND about 11 years ago

OK, so just ignore the last 3 messages. The behaviour they comments was modified in Rudder 2.3, when "administration/policy server => clear cache" and "configuration rule serial id" were introduced.

So today, hostname update should be taken into account, in the worst case after a "clear cache". What we really miss is what the bug title and first comments describe: a way to look to inventories update to be able to log them and trigger other action, like a deployment.

Actions #17

Updated by François ARMAND about 11 years ago

  • Status changed from 8 to New
Actions #18

Updated by Jonathan CLARKE about 11 years ago

  • Target version changed from 2.4.0~alpha3 to 2.4.0~alpha4
Actions #19

Updated by François ARMAND almost 11 years ago

  • Target version changed from 2.4.0~alpha4 to 24
Actions #20

Updated by Jonathan CLARKE over 10 years ago

  • Target version changed from 24 to Ideas (not version specific)
Actions #21

Updated by François ARMAND almost 10 years ago

  • Assignee deleted (François ARMAND)
Actions #22

Updated by Benoît PECCATTE almost 8 years ago

  • Category changed from 26 to Web - Nodes & inventories
Actions #23

Updated by François ARMAND over 6 years ago

  • Subject changed from When a node changes hostname we should regenerate the server's promises to Node hostname modification should trigger promises regeneration
Actions #24

Updated by François ARMAND over 6 years ago

  • Related to Bug #8046: Change of Policy Server does not trigger a Policyupdate added
Actions #25

Updated by François ARMAND over 6 years ago

  • Subject changed from Node hostname modification should trigger promises regeneration to Node (hostname,policyserver,...) modification should trigger promises regeneration
  • Description updated (diff)
  • Target version changed from Ideas (not version specific) to 2.11.21
Actions #26

Updated by François ARMAND over 6 years ago

  • Tracker changed from User story to Bug
  • Assignee set to François ARMAND
  • Reproduced set to No

Changing to bug due to production problem arising from it, like: http://www.rudder-project.org/redmine/issues/8046#note-16

Actions #27

Updated by François ARMAND over 6 years ago

  • translation missing: en.field_tag_list set to Next minor release
Actions #28

Updated by François ARMAND over 6 years ago

  • Related to Bug #5316: If policy server hostname changes, the generated promises never take into account the new value added
Actions #29

Updated by François ARMAND over 6 years ago

  • Has duplicate User story #8247: Changing hostname or policy server of one node force regeneration of all rules on the node added
Actions #30

Updated by François ARMAND over 6 years ago

  • Has duplicate deleted (User story #8247: Changing hostname or policy server of one node force regeneration of all rules on the node)
Actions #31

Updated by François ARMAND over 6 years ago

  • Related to deleted (Bug #8046: Change of Policy Server does not trigger a Policyupdate)
Actions #32

Updated by François ARMAND over 6 years ago

  • Has duplicate Bug #8046: Change of Policy Server does not trigger a Policyupdate added
Actions #33

Updated by Vincent MEMBRÉ over 6 years ago

  • Target version changed from 2.11.21 to 2.11.22
Actions #34

Updated by Vincent MEMBRÉ over 6 years ago

  • Target version changed from 2.11.22 to 2.11.23
Actions #35

Updated by Vincent MEMBRÉ over 6 years ago

  • Target version changed from 2.11.23 to 2.11.24
Actions #36

Updated by Vincent MEMBRÉ over 6 years ago

  • Target version changed from 2.11.24 to 308
Actions #37

Updated by Vincent MEMBRÉ over 6 years ago

  • Target version changed from 308 to 3.1.14
Actions #38

Updated by Vincent MEMBRÉ over 6 years ago

  • Target version changed from 3.1.14 to 3.1.15
Actions #39

Updated by Vincent MEMBRÉ over 6 years ago

  • Target version changed from 3.1.15 to 3.1.16
Actions #40

Updated by Vincent MEMBRÉ over 6 years ago

  • Target version changed from 3.1.16 to 3.1.17
Actions #41

Updated by François ARMAND about 6 years ago

  • Status changed from New to In progress
Actions #42

Updated by Vincent MEMBRÉ about 6 years ago

  • Target version changed from 3.1.17 to 3.1.18
Actions #43

Updated by Vincent MEMBRÉ almost 6 years ago

  • Target version changed from 3.1.18 to 3.1.19
Actions #44

Updated by Alexis Mousset almost 6 years ago

  • Status changed from In progress to New
Actions #45

Updated by François ARMAND almost 6 years ago

  • Severity set to Minor - inconvenience | misleading | easy workaround
  • User visibility set to Operational - other Techniques | Technique editor | Rudder settings
Actions #46

Updated by Vincent MEMBRÉ almost 6 years ago

  • Target version changed from 3.1.19 to 3.1.20
  • Priority set to 0
Actions #47

Updated by Jonathan CLARKE almost 6 years ago

  • Assignee deleted (François ARMAND)
Actions #48

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 3.1.20 to 3.1.21
Actions #49

Updated by François ARMAND over 5 years ago

  • translation missing: en.field_tag_list deleted (Next minor release)
  • Severity changed from Minor - inconvenience | misleading | easy workaround to Major - prevents use of part of Rudder | no simple workaround
  • Priority changed from 0 to 36
Actions #50

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 3.1.21 to 3.1.22
Actions #51

Updated by Benoît PECCATTE over 5 years ago

  • Priority changed from 36 to 52
Actions #52

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 3.1.22 to 3.1.23
Actions #53

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 3.1.23 to 3.1.24
Actions #54

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 3.1.24 to 3.1.25
Actions #55

Updated by François ARMAND about 5 years ago

  • Target version changed from 3.1.25 to 4.1.9
Actions #56

Updated by François ARMAND about 5 years ago

  • Status changed from New to In progress
  • Assignee set to François ARMAND
Actions #57

Updated by François ARMAND about 5 years ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from François ARMAND to Nicolas CHARLES
  • Pull Request set to https://github.com/Normation/rudder/pull/1803
Actions #58

Updated by François ARMAND about 5 years ago

  • Status changed from Pending technical review to Pending release
Actions #59

Updated by Vincent MEMBRÉ about 5 years ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 4.1.9 and 4.2.3 which were released today.

Actions

Also available in: Atom PDF