Webhook jinja template

[Sergey Korobkov]

Hi all,

Does anyone know how can I refer to a particular custom_field change in jinja2 template? I mean I want a webhook being called conditionally when custom_field updated && not null.

TIA,

Sergei

[Brian Candler]

I'm afraid the webhook doesn't give you the "before and after" values, so you can't tell which fields have changed, custom or otherwise.

https://github.com/netbox-community/netbox/issues/3451

[Sergey Korobkov]

Would you advice the best way though, I want the device status being changed depending on the condition if a particular custom value updated or not.

For example, custom_field name updated to "reserved_by":"username" ==>change device status to "planned";

custom_field cleared out (null) ==>  change device status to "inventory";

ср, 6 янв. 2021 г. в 19:36, Brian Candler <b.ca...@pobox.com>:

--
You received this message because you are subscribed to a topic in the Google Groups "NetBox" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/netbox-discuss/-Mrgzsd06EE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to netbox-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/netbox-discuss/dd47b5f4-405c-4b04-8f52-2580b3cd3b7fn%40googlegroups.com.

[Brian Candler]

It sounds to me that what you *really* want is a way to hook some custom logic into the Django ORM update cycle: that would mean your code could reject certain changes, or perform knock-on changes inside the same database transaction.  But Netbox doesn't support that either.  If it goes too far down that line, it will end up looking like Salesforce anyway.

I also observe that using a webhook doesn't give you any consistency guarantees: e.g. there will be a period of time between the reserved_by field changing, and the device status being updated.  There are also potential race conditions if a webhook triggers an immediate write back to Netbox.

Anyway, the options I can think of are:

1. Write a webhook which keeps a copy of all previous data, and whenever it receives a message, compares old with new and then updates its local copy.

2. Write something using Postgres triggers and stored procedures, and bolt it directly into the database.  The trigger/SP would write to an extra table, and an external process monitors that table. (TBH, I wish this is how Netbox webhooks worked in the first place).

3. You deploy some third-party Change Data Capture (CDC) solution for Postgres, e.g. to stream Postgres changes into Kafka, and read that feed.

4. Move your lifecycle management into a separate system, instead of Netbox custom fields, and post updates to Netbox as appropriate.

Option 1 doesn't solve your problem of wanting to prevent the webhook triggering in the first place. However you could build an intermediate webhook with this functionality, which in turn calls a remote webhook when the conditions are right.

Option 2 is entirely your responsibility to build and maintain at low level.

Option 3 may reduce your low-level database work, at the cost of finding and deploying a CDC solution that meets your needs.

Option 4 means building a new system for managing lifecycle.