Multiple Webhook fires when updating DNS field on IP address.

[kollross]

I have an even rule setup to fire a webhook whenever an Netbox DNS Record is modified. When changing the DNS name under IPAM->IP Address, it ends up firing 4 Webhooks for a single edit. I suspect Netbox is doing something in the background where multiple objects are in fact being updated, but I'm trying to figure out how to avoid firing off 4 jobs for a single task.

[peteeckel]

You didn't mention what the four webhook fires were about, but from what you wrote I think it's easy to guess.

You have both SOA serial generation and PTR generation enabled, and you have the reverse zone for the IP address in NetBox DNS, correct?

In this case, four records will be updated when you create or update the DNS name for an IP address with DNSsync enabled:

• Update the PTR record for the address you edited
• Update the SOA record for the zone of the PTR record
• Update the A/AAAA record matching the DNS name
• Update the SOA record for the zone of the A/AAAA record

(I'm currently not sure about the order, but it's easy to figure out ). The order is deterministic.

So, four records will be updated, hence four webhooks fire.

[kollross]

Correct, I suspected that was the case. I'm just trying to figure out a work around to having that webhook fire 4 times in rapid succession.

[peteeckel]

Correct, I suspected that was the case. I'm just trying to figure out a work around to having that webhook fire 4 times in rapid succession.

You could turn off auto PTR and SOA SERIAL generation.

If you don't, four records are updated, so four webhook invocations are performed. That's the way NetBox works, I don't have any influence on it.

Solution idea: You could create a custom script that's triggered by record updates, waits for a given time, then triggers another web hook. It detects if it's already running and terminates without doing anything if it is.

[alehaa]

@peteeckel I somehow have a similar problem in my deployment. Updating a bunch of records fires N webhooks and in my case N synchronization jobs from NetBox to my DNS server.

I'm thinking about filing a FR at NetBox, making your idea about the script part of the event rule logic. However, I still have no optimal solution on how to solve this. My idea was to make an event "asynchronous". If marked as such, an event will not be fired immediately, but scheduled as a background job in x minutes instead. If an event for the same object occurs in the meantime, it would simply be skipped. However, the event rule would only process data from the first event, as I see no way to efficiently add more events to the scheduled job. Also, this might require some kind of delegation, i.e. when records change, we're really interested in "zone xyz.com changed" instead of the individual record. Could be another feature.

An additional but similar use case would be switch interfaces: Changing 20 interfaces on a switch shouldn't trigger 20 deployment jobs. But after some time, the switch should somehow be deployed for all interfaces together.

[peteeckel]

@alehaa That's definitely a good FR for NetBox Core. I'm not sure yet what the implementation should look like, but the issue is definitely more wide-spread than just for NetBox DNS only, and I suspect that the use cases will increase rapidly as people start adopting NetBox with event driven automation.

Until there is a more generic solution, we can make use of already existing functionality.

One approach would be to use NetBox branching and deploy a new configuration not on the configuration change itself, but on merging the branch. Unfortunately in my experience (which is mirrored by the open issues in the netbox-branching plugin repository) the functionality is still too wonky for me to consider it fit for production, and it also requires fairly extensive changes to plugins in order to make non-trivial operations work properly. So IMHO that's not something we can use to solve short-term issues.

The approach I mentioned above, i.e. using a delayed job, seems more promising in the short term. One element I would consider is using a custom field on the zone level that records the time or SOA SERIAL of the last successful deployment. The (central) job that is doing the actual deployment can then decide which zones to update. For scheduling that job it could be useful to take a look at the EVENTS_PIPELINE mechanism in NetBox which was introduced in NetBox 4.2 and is pretty sparsely documented at the moment. The general idea I have is not to do the scheduling in the script started by the event hook itself, but centrally in the events pipeline which should make the job of re-scheduling the job easier than doing it from another job.

There's yet another approach that I don't like too much but that works as well is to make all zones dynamic and update records on-the-fly using nsupdate or dnspython's dns.update.Update. The disadvantages I see is the requirement to make all zones dynamic and the fact that the dynamic updates trigger at least IXFRs on the slaves again, which only shifts the problem from the deployment level to the operational DNS level.