Netbox: API support for bulk object deletion

[lamoni]

Environment

• Python version: Python 3.7
• NetBox version: 2.6.2

Proposed Functionality

Allow bulk deletion of sites and devices (preferably anything) through API end-point.

Use Case

We have a use case that requires bulk deletion of sites and devices for automated deployment and testing of a Netbox instance. Currently, we have to iterate through the list of objects and delete them 1 by 1 (i.e. 1 HTTP request per device/site/whatever), this can take upwards of minutes. We can bulk create just fine (which reduced time to finish by a lot), but can't bulk delete. The GUI has the ability, but there isn't an API endpoint to do so.

[lampwins]

This has been in the back of my mind for a while, and I am surprised it has not come up before now. As we look to make UI improvements down the road, this will be needed.

We should be able to do this with a non-detail action route on our modified ModelViewSet class.

I would want to be able to pass a list of PKs or a list of objects that use the same queryset field lookup logic we implemented not long ago, as the quest body.

For example for sites, you could pass either:

[1, 4, 6]

Or

[{"name": "Site A"}, {"name": "Site B"}, {"name": "Site C"}]

[gunnertwin]

I also have a requirement for this. I'm pulling data from Azure and want my netbox to match my Azure estate exactly. So if someone deletes a vnet in Azure, that vnet also needs to be removed in Netbox. So I would like to run my pipeline which will initially bulk delete everything and then add the current state of Azure

[jeremystretch]

I've made good progress on this in the branch 3436-api-bulk-update, however I've hit a wall troubleshooting an OpenAPI schema generation issue. The introduction of the bulk delete view and subsequent support for the DELETE HTTP action under a list endpoint results in a duplicate operation ID when generating the schema:

SwaggerValidationError at /api/docs/

spec validation failed: {'ssv': 'Duplicate operationId: circuits_circuit-terminations_delete'}

[jeremystretch]

After _a lot_ of digging, the sticking point seems to be the get_keys() method of DRF's CoreAPI SchemaGenerator class. Essentially, because we've introduced a custom operation (bulk_destroy), it's getting assigned a schema operation ID based on the HTTP method (DELETE), which conflicts with the DELETE operation on the detail route (i.e. DELETE /api/dcim/sites/1/).

At present, the only workaround seems to be to replicate both the drf_yasg and rest_framework schema generators, since the non-default actions are hard-coded. This probably justifies raising upstream to DRF and/or drf_yasg.

[jeremystretch]

I figured out a workaround by monkey-patching DRF's is_custom_action() function. Obviously not ideal, but it's definitely the lowest-touch approach. It's probably still worth pursuing upstream, but given the current state of drf_yasg versus DRF's internal OpenAPI schema development, I'm not sure where to start.