User story (meta) #1411

When a node changes hostname we should regenerate the server's promises

Added by Jonathan CLARKE about 3 years ago. Updated over 1 year ago.

Status:New Start date:2011-06-28
Priority:2 Due date:
Assignee:- % Done:

0%

Category:Inventory (webapp, Fusion)
Target version:Ideas (not version specific)
Needs translating:No

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.

History

#1 Updated by Jonathan CLARKE about 3 years ago

  • Target version changed from 15 to 16

#2 Updated by Jonathan CLARKE about 3 years ago

  • Target version changed from 16 to 19

#3 Updated by François ARMAND almost 3 years ago

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

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

  • Status changed from 2 to Discussion

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

  • Target version changed from 19 to 21

#9 Updated by Jonathan CLARKE almost 3 years ago

  • Target version changed from 21 to 23

#10 Updated by Jonathan CLARKE almost 3 years ago

  • Target version changed from 23 to Ideas (2.4 specific)

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

  • Assignee deleted (François ARMAND)

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

  • Target version changed from Ideas (2.4 specific) to Ideas (2.5 specific)

#13 Updated by François ARMAND over 2 years ago

  • Status changed from Discussion to Qualified
  • Assignee set to François ARMAND
  • Target version changed from Ideas (2.5 specific) to 2.4.0~alpha3
  • Needs translating set to No

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 2 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 2 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 2 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 2 years ago

  • Status changed from Qualified to New

#18 Updated by Jonathan CLARKE over 2 years ago

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

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

  • Target version changed from 2.4.0~alpha4 to Ideas (2.5 specific)

#20 Updated by Jonathan CLARKE about 2 years ago

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

#21 Updated by François ARMAND over 1 year ago

  • Assignee deleted (François ARMAND)

Also available in: Atom PDF