Project

General

Profile

Actions

Bug #1411

closed

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

Added by Jonathan CLARKE almost 10 years ago. Updated over 3 years ago.

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

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

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 almost 10 years ago

  • Target version changed from 15 to 16
Actions #2

Updated by Jonathan CLARKE over 9 years ago

  • Target version changed from 16 to 19
Actions #3

Updated by François ARMAND over 9 years ago

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

Updated by François ARMAND over 9 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 9 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 9 years ago

  • Status changed from 2 to Discussion
Actions #7

Updated by François ARMAND over 9 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 9 years ago

  • Target version changed from 19 to 21
Actions #9

Updated by Jonathan CLARKE over 9 years ago

  • Target version changed from 21 to 23
Actions #10

Updated by Jonathan CLARKE over 9 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 9 years ago

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

Updated by François ARMAND over 9 years ago

  • Target version changed from 18 to 24
Actions #13

Updated by François ARMAND over 9 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 over 9 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 over 9 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 over 9 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 over 9 years ago

  • Status changed from 8 to New
Actions #18

Updated by Jonathan CLARKE over 9 years ago

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

Updated by François ARMAND over 9 years ago

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

Updated by Jonathan CLARKE almost 9 years ago

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

Updated by François ARMAND about 8 years ago

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

Updated by Benoît PECCATTE about 6 years ago

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

Updated by François ARMAND about 5 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 about 5 years ago

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

Updated by François ARMAND about 5 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 about 5 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 almost 5 years ago

  • Tags set to Next minor release
Actions #28

Updated by François ARMAND almost 5 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 almost 5 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 almost 5 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 almost 5 years ago

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

Updated by François ARMAND almost 5 years ago

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

Updated by Vincent MEMBRÉ almost 5 years ago

  • Target version changed from 2.11.21 to 2.11.22
Actions #34

Updated by Vincent MEMBRÉ almost 5 years ago

  • Target version changed from 2.11.22 to 2.11.23
Actions #35

Updated by Vincent MEMBRÉ almost 5 years ago

  • Target version changed from 2.11.23 to 2.11.24
Actions #36

Updated by Vincent MEMBRÉ over 4 years ago

  • Target version changed from 2.11.24 to 308
Actions #37

Updated by Vincent MEMBRÉ over 4 years ago

  • Target version changed from 308 to 3.1.14
Actions #38

Updated by Vincent MEMBRÉ over 4 years ago

  • Target version changed from 3.1.14 to 3.1.15
Actions #39

Updated by Vincent MEMBRÉ over 4 years ago

  • Target version changed from 3.1.15 to 3.1.16
Actions #40

Updated by Vincent MEMBRÉ over 4 years ago

  • Target version changed from 3.1.16 to 3.1.17
Actions #41

Updated by François ARMAND over 4 years ago

  • Status changed from New to In progress
Actions #42

Updated by Vincent MEMBRÉ over 4 years ago

  • Target version changed from 3.1.17 to 3.1.18
Actions #43

Updated by Vincent MEMBRÉ about 4 years ago

  • Target version changed from 3.1.18 to 3.1.19
Actions #44

Updated by Alexis MOUSSET about 4 years ago

  • Status changed from In progress to New
Actions #45

Updated by François ARMAND about 4 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É about 4 years ago

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

Updated by Jonathan CLARKE about 4 years ago

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

Updated by Vincent MEMBRÉ almost 4 years ago

  • Target version changed from 3.1.20 to 3.1.21
Actions #49

Updated by François ARMAND almost 4 years ago

  • Tags 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É almost 4 years ago

  • Target version changed from 3.1.21 to 3.1.22
Actions #51

Updated by Benoît PECCATTE almost 4 years ago

  • Priority changed from 36 to 52
Actions #52

Updated by Vincent MEMBRÉ almost 4 years ago

  • Target version changed from 3.1.22 to 3.1.23
Actions #53

Updated by Vincent MEMBRÉ over 3 years ago

  • Target version changed from 3.1.23 to 3.1.24
Actions #54

Updated by Vincent MEMBRÉ over 3 years ago

  • Target version changed from 3.1.24 to 3.1.25
Actions #55

Updated by François ARMAND over 3 years ago

  • Target version changed from 3.1.25 to 4.1.9
Actions #56

Updated by François ARMAND over 3 years ago

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

Updated by François ARMAND over 3 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 over 3 years ago

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

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