NetBox Webhooks HTTP Responses.

[remchuk]

Hey everybody!

So I'm trying to make use of NetBox to integrate configuration into my environment., to do this I'm using webhook and a Flask listener.

What I'm trying to understand , is there a way to prompt HTTP responses to a user when creating a VLAN for example?

Like let's say a user is adding a VLAN is to the NetBox and a webhook is triggered and a script is ran by the flask and let's say that it didn't work and the flask failed for some reason , like wrong Tag or something or one device didn't work. I can prompt a HTTP response by the Flask but is there a way for a user in the NetBox to see it ?

[candlerb]

Webhooks are queued and asynchronous, so Netbox will have returned to the next page already.

You can see the results in Admin > Background tasks, but the admin section is only visible to "Staff" users.

Alternatively, your webhook receiver could make a call back to the Netbox REST API to update some object, like setting a comment field on the relevant VLAN object.

[remchuk]

@candlerb there is no way to make the NetBox creation of something depend on the output of the flask ?

[candlerb]

Not using webhooks, because like I say, they are triggered in the background; and this occurs after the update has been committed to the database. Also, they will be triggered if the update comes from any other source - like the REST API - where there's no user to interact with.

If you want to validate things before they are committed, then I suggest you put your "create VLAN" task into a Custom Script: if this aborts, it rolls back the transaction. That's a fully supported way of working, and I don't see any problem with making external calls as it runs. You might not want to hold a database transaction open for too long, but a few seconds should be fine.

I suppose in principle it might be possible to have a Custom Validator which makes external API calls, but I'm not sure whether it's a good idea to have a custom validator with side-effects, so I would not recommend that approach.

Also note that if your webhook returns a 4xx/5xx error then it will be marked as "failed", and it's possible to retry it (but that requires going into the Admin interface too).

Therefore, you might want to consider separately:

1. Whether the user was able to successfully add valid data into Netbox (the source-of-truth, "how things should be")
2. Whether the external task triggered by the webhook was able to replicate this into the real world - and if so, whether retrying might fix it, or if you need to escalate the failure for manual resolution - or indeed, whether the best resolution is to undo the change the user originally requested.

[remchuk]

@candlerb So you what you say, is that using custom scripts I can make changes in my environment and also within ?

I mean using custom script can also abort the let's say the creation of vlan in my environment and in the netbox if it fails on my switch ?

[candlerb]

Yes: your custom script can make outgoing connections (e.g. using requests or napalm), and it can use the Django ORM to make changes within Netbox. If it fails, then the database transaction will be rolled back, but it would be up to you to undo any changes you've already made in your external network.

You should beware that your processing shouldn't take too long, or you'll exceed the webserver timeout (and/or your users may navigate away). That was the reason for webhooks being converted to background tasks in the first place.

TBH, a background workflow with a state machine is a safer way of doing updates to your live network. You can divide the work into multiple steps; retry steps that have intermittent errors; and have explicit compensation steps if you need to undo partial changes. But that's really outside the scope of Netbox itself. Netbox does let you write your own background tasks, but it's not a fully-fledged workflow engine.

That's why I was thinking that it would be a good idea to separate out the initial validation of the request (to make sure it should be deployable), which can be confirmed synchronously back to the user, versus the actual deployment, which can take place in the background.

You might also need to consider interlocking, e.g. if two different users make a change which touches the same device, you might want to serialize those changes.

[remchuk]

Well that gives a lot to think about , Currently there is a flask server listening for webhooks and running configuration on our environment, which is great but there is no feedback to our users in the Netbox.

Your way seems a lot better.

Thanks a lot for putting your time into my question, I really appreciate it.