Project

General

Profile

Bug #1411

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

Added by Jonathan CLARKE over 5 years ago. Updated 3 days ago.

Status:
New
Priority:
2
Category:
Web - Nodes & inventories
Target version:
Start date:
2011-06-28
Due date:
% Done:

0%

Pull Request:
Reproduced:
No
How to reproduce:
Found in version(s):
Tags: Next minor release

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 value New 2014-07-24
Duplicated by Rudder - Bug #8046: Change of Policy Server does not trigger a Policyupdate Rejected 2016-03-08

History

#1 Updated by Jonathan CLARKE about 5 years ago

  • Target version changed from 15 to 16

#2 Updated by Jonathan CLARKE about 5 years ago

  • Target version changed from 16 to 19

#3 Updated by François ARMAND about 5 years ago

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

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

  • Status changed from 2 to Discussion

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

  • Target version changed from 19 to 21

#9 Updated by Jonathan CLARKE about 5 years ago

  • Target version changed from 21 to 23

#10 Updated by Jonathan CLARKE about 5 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 about 5 years ago

  • Assignee deleted (François ARMAND)

#12 Updated by François ARMAND almost 5 years ago

  • Target version changed from 18 to 24

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

  • Status changed from 8 to New

#18 Updated by Jonathan CLARKE over 4 years ago

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

#19 Updated by François ARMAND over 4 years ago

  • Target version changed from 2.4.0~alpha4 to 24

#20 Updated by Jonathan CLARKE over 4 years ago

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

#21 Updated by François ARMAND over 3 years ago

  • Assignee deleted (François ARMAND)

#22 Updated by Benoît PECCATTE over 1 year ago

  • Category changed from 26 to Web - Nodes & inventories

#23 Updated by François ARMAND 5 months 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 5 months ago

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

#25 Updated by François ARMAND 5 months 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 5 months 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 5 months ago

  • Tags set to Next minor release

#28 Updated by François ARMAND 5 months 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 5 months ago

  • Duplicated by Bug #8247: Changing hostname or policy server of one node force regeneration of all rules on the node added

#30 Updated by François ARMAND 5 months ago

  • Duplicated by deleted (Bug #8247: Changing hostname or policy server of one node force regeneration of all rules on the node)

#31 Updated by François ARMAND 5 months ago

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

#32 Updated by François ARMAND 5 months ago

  • Duplicated by Bug #8046: Change of Policy Server does not trigger a Policyupdate added

#33 Updated by Vincent MEMBRÉ 4 months ago

  • Target version changed from 2.11.21 to 2.11.22

#34 Updated by Vincent MEMBRÉ 4 months ago

  • Target version changed from 2.11.22 to 2.11.23

#35 Updated by Vincent MEMBRÉ 2 months ago

  • Target version changed from 2.11.23 to 2.11.24

#36 Updated by Vincent MEMBRÉ about 1 month ago

  • Target version changed from 2.11.24 to 308

#37 Updated by Vincent MEMBRÉ 19 days ago

  • Target version changed from 308 to 3.1.14

#38 Updated by Vincent MEMBRÉ 3 days ago

  • Target version changed from 3.1.14 to 3.1.15

Also available in: Atom PDF