Delete Project is not working if we have mutliple test and findings

[vishal-gurnaney]

Hi All,
I performed the Dependency Track and Defect Dojo integrations. Post that i have multiple test data into the Dojo project.
I am trying to Delete the project it takes forever, I checked the logs its generating alerts and unable to delete and after 15-20 mins it crashes.

• Do we have any database clean-up script.
• Any other mechanism to Delete the project.

I am always going to have huge data into my project, need some clean-up feature or else not possible to use Defect-Dojo.
Please share you views.

[mtesauro]

There's nothing broken with deleting projects in the DefectDojo code. If you're having issues, it's likely a performance tuning issue. If you run out of RAM or CPU during the cascading delete, then you can run into issues. For instance, if you're running DefectDojo in containers, the container can be killed by the OOM killer depending on the specifics of the situation.

You didn't provide any details on the resources available to DefectDojo, how you deployed it or what version you're using so it's not possible to provide more then general advice of give your DefectDojo install more resources.

[EvkaAki]

I have the same issue. I guess it's exactly the case you describe, the whole CPU is used and container is killed. Can you provide some info how to resolve this that is not giving more resources to DD? We use much stronger machine that is the minimal requirements and I did every optimalization mentioned in the Defect Dojo documentation. If it's not able handle one test project with couple thousand tests and there is no clean-up script I fail to see how it can be used in production. I cannot purge the whole database every time it happens...we use docker-compose to deploy DD - version 2.33.1 .

[mtesauro]

Deleting via the API takes less resources then the UI is the only thing that jumps to mind if you aren't able to increase the resources or change the constraints on the container.

If you're really hardware constrained, you can start at the "bottom" of the data model and work your way up. e.g. delete findings, then tests, then engagements then products, then product_types. This would be basically turning the cascading deletes Django uses into a manual process but will require less resources since the number of objects your deleting will be smaller. This would be either a series of manually made API calls or some code you write to do those calls for you.
Data model: https://documentation.defectdojo.com/usage/models/

If you are doing this in the UI, add DD_DELETE_PREVIEW in local_setting.py to stop DefectDojo from providing a preview of what will be deleted in the confirmation screen. This will reduce compute resource used when deleting via the UI.

DD_DELETE_PREVIEW defaults to true (settings.dist.py), change it to false in local_settings.py to override the default.
https://github.com/DefectDojo/django-DefectDojo/blob/master/dojo/settings/settings.dist.py#L274-L276