Rudder

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.

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?

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.

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.

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!

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.