Bug #1411
closedNode (hostname,policyserver,...) modification should trigger promises regeneration
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.
Updated by Jonathan CLARKE over 13 years ago
- Target version changed from 15 to 16
Updated by Jonathan CLARKE about 13 years ago
- Target version changed from 16 to 19
Updated by François ARMAND about 13 years ago
- Assignee set to François ARMAND
- Priority changed from 3 to 2
Updated by François ARMAND about 13 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.
Updated by Jonathan CLARKE about 13 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?
Updated by Jonathan CLARKE about 13 years ago
- Status changed from 2 to Discussion
Updated by François ARMAND about 13 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.
Updated by Jonathan CLARKE about 13 years ago
- Target version changed from 19 to 21
Updated by Jonathan CLARKE about 13 years ago
- Target version changed from 21 to 23
Updated by Jonathan CLARKE about 13 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.
Updated by François ARMAND about 13 years ago
- Assignee deleted (
François ARMAND)
Updated by François ARMAND almost 13 years ago
- Target version changed from 18 to 24
Updated by François ARMAND almost 13 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.
Updated by François ARMAND almost 13 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.
Updated by Jonathan CLARKE almost 13 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!
Updated by François ARMAND almost 13 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.
Updated by Jonathan CLARKE almost 13 years ago
- Target version changed from 2.4.0~alpha3 to 2.4.0~alpha4
Updated by François ARMAND almost 13 years ago
- Target version changed from 2.4.0~alpha4 to 24
Updated by Jonathan CLARKE over 12 years ago
- Target version changed from 24 to Ideas (not version specific)
Updated by François ARMAND over 11 years ago
- Assignee deleted (
François ARMAND)
Updated by Benoît PECCATTE over 9 years ago
- Category changed from 26 to Web - Nodes & inventories
Updated by François ARMAND over 8 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
Updated by François ARMAND over 8 years ago
- Related to Bug #8046: Change of Policy Server does not trigger a Policyupdate added
Updated by François ARMAND over 8 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
Updated by François ARMAND over 8 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
Updated by François ARMAND over 8 years ago
- Translation missing: en.field_tag_list set to Next minor release
Updated by François ARMAND over 8 years ago
- Related to Bug #5316: If policy server hostname changes, the generated promises never take into account the new value added
Updated by François ARMAND over 8 years ago
- Has duplicate User story #8247: Changing hostname or policy server of one node force regeneration of all rules on the node added
Updated by François ARMAND over 8 years ago
- Has duplicate deleted (User story #8247: Changing hostname or policy server of one node force regeneration of all rules on the node)
Updated by François ARMAND over 8 years ago
- Related to deleted (Bug #8046: Change of Policy Server does not trigger a Policyupdate)
Updated by François ARMAND over 8 years ago
- Has duplicate Bug #8046: Change of Policy Server does not trigger a Policyupdate added
Updated by Vincent MEMBRÉ over 8 years ago
- Target version changed from 2.11.21 to 2.11.22
Updated by Vincent MEMBRÉ over 8 years ago
- Target version changed from 2.11.22 to 2.11.23
Updated by Vincent MEMBRÉ over 8 years ago
- Target version changed from 2.11.23 to 2.11.24
Updated by Vincent MEMBRÉ about 8 years ago
- Target version changed from 2.11.24 to 308
Updated by Vincent MEMBRÉ about 8 years ago
- Target version changed from 308 to 3.1.14
Updated by Vincent MEMBRÉ about 8 years ago
- Target version changed from 3.1.14 to 3.1.15
Updated by Vincent MEMBRÉ about 8 years ago
- Target version changed from 3.1.15 to 3.1.16
Updated by Vincent MEMBRÉ about 8 years ago
- Target version changed from 3.1.16 to 3.1.17
Updated by François ARMAND about 8 years ago
- Status changed from New to In progress
Updated by Vincent MEMBRÉ almost 8 years ago
- Target version changed from 3.1.17 to 3.1.18
Updated by Vincent MEMBRÉ over 7 years ago
- Target version changed from 3.1.18 to 3.1.19
Updated by Alexis Mousset over 7 years ago
- Status changed from In progress to New
Updated by François ARMAND over 7 years ago
- Severity set to Minor - inconvenience | misleading | easy workaround
- User visibility set to Operational - other Techniques | Technique editor | Rudder settings
Updated by Vincent MEMBRÉ over 7 years ago
- Target version changed from 3.1.19 to 3.1.20
- Priority set to 0
Updated by Vincent MEMBRÉ over 7 years ago
- Target version changed from 3.1.20 to 3.1.21
Updated by François ARMAND over 7 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
Updated by Vincent MEMBRÉ over 7 years ago
- Target version changed from 3.1.21 to 3.1.22
Updated by Vincent MEMBRÉ about 7 years ago
- Target version changed from 3.1.22 to 3.1.23
Updated by Vincent MEMBRÉ about 7 years ago
- Target version changed from 3.1.23 to 3.1.24
Updated by Vincent MEMBRÉ about 7 years ago
- Target version changed from 3.1.24 to 3.1.25
Updated by François ARMAND almost 7 years ago
- Target version changed from 3.1.25 to 4.1.9
Updated by François ARMAND almost 7 years ago
- Status changed from New to In progress
- Assignee set to François ARMAND
Updated by François ARMAND almost 7 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
Updated by François ARMAND almost 7 years ago
- Status changed from Pending technical review to Pending release
Applied in changeset rudder|8370944eaaef87be409fdf143f1cc2644b1bee0b.
Updated by Vincent MEMBRÉ almost 7 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.
- 4.1.9: Announce Changelog
- 4.2.3: Announce Changelog
- Download: https://www.rudder-project.org/site/get-rudder/downloads/