Project

General

Profile

Bug #1411

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

Added by Jonathan CLARKE almost 8 years ago. Updated over 1 year 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 PolicyupdateRejected2016-03-08Actions

Associated revisions

Revision 8370944e (diff)
Added by François ARMAND over 1 year ago

Fixes #1411: Node (hostname,policyserver,...) modification should trigger promises regeneration

Revision 4bbc8f9a (diff)
Added by François ARMAND over 1 year ago

Fixes #1411: Node (hostname,policyserver,...) modification should trigger promises regeneration

History

#1

Updated by Jonathan CLARKE almost 8 years ago

  • Target version changed from 15 to 16
#2

Updated by Jonathan CLARKE almost 8 years ago

  • Target version changed from 16 to 19
#3

Updated by François ARMAND almost 8 years ago

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

Updated by François ARMAND almost 8 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.

#5

Updated by Jonathan CLARKE almost 8 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?

#6

Updated by Jonathan CLARKE almost 8 years ago

  • Status changed from 2 to Discussion
#7

Updated by François ARMAND almost 8 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.

#8

Updated by Jonathan CLARKE almost 8 years ago

  • Target version changed from 19 to 21
#9

Updated by Jonathan CLARKE over 7 years ago

  • Target version changed from 21 to 23
#10

Updated by Jonathan CLARKE over 7 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.

#11

Updated by François ARMAND over 7 years ago

  • Assignee deleted (François ARMAND)
#12

Updated by François ARMAND over 7 years ago

  • Target version changed from 18 to 24
#13

Updated by François ARMAND over 7 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.

#14

Updated by François ARMAND over 7 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.

#15

Updated by Jonathan CLARKE over 7 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!

#16

Updated by François ARMAND over 7 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.

#17

Updated by François ARMAND over 7 years ago

  • Status changed from 8 to New
#18

Updated by Jonathan CLARKE over 7 years ago

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

Updated by François ARMAND over 7 years ago

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

Updated by Jonathan CLARKE about 7 years ago

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

Updated by François ARMAND about 6 years ago

  • Assignee deleted (François ARMAND)
#22

Updated by Benoît PECCATTE over 4 years ago

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

Updated by François ARMAND about 3 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
#24

Updated by François ARMAND about 3 years ago

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

Updated by François ARMAND about 3 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
#26

Updated by François ARMAND about 3 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

#27

Updated by François ARMAND about 3 years ago

  • Tags set to Next minor release
#28

Updated by François ARMAND about 3 years ago

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

Updated by François ARMAND about 3 years ago

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

Updated by François ARMAND about 3 years ago

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

Updated by François ARMAND about 3 years ago

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

Updated by François ARMAND about 3 years ago

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

Updated by Vincent MEMBRÉ about 3 years ago

  • Target version changed from 2.11.21 to 2.11.22
#34

Updated by Vincent MEMBRÉ about 3 years ago

  • Target version changed from 2.11.22 to 2.11.23
#35

Updated by Vincent MEMBRÉ almost 3 years ago

  • Target version changed from 2.11.23 to 2.11.24
#36

Updated by Vincent MEMBRÉ almost 3 years ago

  • Target version changed from 2.11.24 to 308
#37

Updated by Vincent MEMBRÉ almost 3 years ago

  • Target version changed from 308 to 3.1.14
#38

Updated by Vincent MEMBRÉ over 2 years ago

  • Target version changed from 3.1.14 to 3.1.15
#39

Updated by Vincent MEMBRÉ over 2 years ago

  • Target version changed from 3.1.15 to 3.1.16
#40

Updated by Vincent MEMBRÉ over 2 years ago

  • Target version changed from 3.1.16 to 3.1.17
#41

Updated by François ARMAND over 2 years ago

  • Status changed from New to In progress
#42

Updated by Vincent MEMBRÉ over 2 years ago

  • Target version changed from 3.1.17 to 3.1.18
#43

Updated by Vincent MEMBRÉ over 2 years ago

  • Target version changed from 3.1.18 to 3.1.19
#44

Updated by Alexis MOUSSET over 2 years ago

  • Status changed from In progress to New
#45

Updated by François ARMAND about 2 years ago

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

Updated by Vincent MEMBRÉ about 2 years ago

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

Updated by Jonathan CLARKE about 2 years ago

  • Assignee deleted (François ARMAND)
#48

Updated by Vincent MEMBRÉ about 2 years ago

  • Target version changed from 3.1.20 to 3.1.21
#49

Updated by François ARMAND about 2 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
#50

Updated by Vincent MEMBRÉ about 2 years ago

  • Target version changed from 3.1.21 to 3.1.22
#51

Updated by Benoît PECCATTE almost 2 years ago

  • Priority changed from 36 to 52
#52

Updated by Vincent MEMBRÉ almost 2 years ago

  • Target version changed from 3.1.22 to 3.1.23
#53

Updated by Vincent MEMBRÉ almost 2 years ago

  • Target version changed from 3.1.23 to 3.1.24
#54

Updated by Vincent MEMBRÉ over 1 year ago

  • Target version changed from 3.1.24 to 3.1.25
#55

Updated by François ARMAND over 1 year ago

  • Target version changed from 3.1.25 to 4.1.9
#56

Updated by François ARMAND over 1 year ago

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

Updated by François ARMAND over 1 year 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
#58

Updated by François ARMAND over 1 year ago

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

Updated by Vincent MEMBRÉ over 1 year 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.

Also available in: Atom PDF