starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

API support for bulk object deletion #2812

New Issue
Closed
opened 2025-12-29 18:22:24 +01:00 by adam · 5 comments
adam commented 2025-12-29 18:22:24 +01:00
Owner
Copy Link

Originally created by @lamoni on GitHub (Aug 19, 2019).

Originally assigned to: @jeremystretch on GitHub.

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.

Originally created by @lamoni on GitHub (Aug 19, 2019). Originally assigned to: @jeremystretch on GitHub. ### 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.
adam added the status: acceptedtype: feature labels 2025-12-29 18:22:24 +01:00
adam closed this issue 2025-12-29 18:22:24 +01:00
adam commented 2025-12-29 18:22:24 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (Aug 19, 2019):

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"}]
@lampwins commented on GitHub (Aug 19, 2019): 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"}] ```
adam commented 2025-12-29 18:22:24 +01:00
Author
Owner
Copy Link

@gunnertwin commented on GitHub (Jun 11, 2020):

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

@gunnertwin commented on GitHub (Jun 11, 2020): 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
adam commented 2025-12-29 18:22:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 15, 2020):

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 commented on GitHub (Sep 15, 2020): 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'} ```
adam commented 2025-12-29 18:22:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 17, 2020):

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 commented on GitHub (Sep 17, 2020): After _a lot_ of digging, the sticking point seems to be the [`get_keys()` method](https://github.com/encode/django-rest-framework/blob/master/rest_framework/schemas/coreapi.py#L171) 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](https://github.com/encode/django-rest-framework/blob/master/rest_framework/schemas/coreapi.py#L29). This probably justifies raising upstream to DRF and/or `drf_yasg`.
adam commented 2025-12-29 18:22:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 22, 2020):

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.

@jeremystretch commented on GitHub (Sep 22, 2020): 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: accepted type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#2812
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?