Introduction

In OpenShift, deleting an application usually means deleting several related resources, not just one object. If you only remove the pod controller and leave image streams, services, routes, or build configs behind, the project stays cluttered and future deployments become harder to reason about.

Identify What Exists

Start by confirming the current project and listing the resources that belong to the app. This prevents the most common mistake: deleting objects in the wrong namespace.

oc project
oc get all
oc get dc,svc,route,is,bc,configmap,secret

If the app is already labeled consistently, inspect by label instead of scanning the entire namespace:

oc get all -l app=myapp
oc get is,bc,configmap,secret -l app=myapp

Older OpenShift setups often use DeploymentConfig rather than Kubernetes Deployment. You can remove a single deployment config directly:

oc delete dc/myapp

That only deletes the deployment config itself. It does not automatically remove services, routes, image streams, build configs, or unrelated secrets.

Delete the Application Resources

When you know the resource names, explicit deletion is the safest option. It makes the cleanup readable and avoids accidental matches.

1oc delete dc/myapp
2oc delete svc/myapp
3oc delete route/myapp
4oc delete bc/myapp
5oc delete is/myapp

For a more complete cleanup, include other objects created during deployment:

oc delete configmap/myapp-config
oc delete secret/myapp-secret

If you want a single command and your labels are reliable, delete by label:

oc delete all -l app=myapp
oc delete is,bc,configmap,secret -l app=myapp

This pattern matters because all is narrower than many people expect. In OpenShift and Kubernetes, all typically covers workload and networking primitives such as pods, services, replica sets, deployments, and deployment configs, but not every resource type in the namespace.

Remove Everything in Another Namespace

Use -n when the target app lives outside the current project. That keeps the command self-contained and easier to review in shell history.

oc delete dc/myapp svc/myapp route/myapp bc/myapp is/myapp -n team-dev

You can preview the target set first:

oc get all -l app=myapp -n team-dev
oc get is,bc,configmap,secret -l app=myapp -n team-dev

If you are cleaning up temporary environments, add --ignore-not-found so reruns do not fail when some resources are already gone.

oc delete dc/myapp svc/myapp route/myapp bc/myapp is/myapp \
  -n team-dev \
  --ignore-not-found

Verify That the Cleanup Worked

After deletion, check whether any dependent objects remain. A route or image stream left behind can make the environment look half-removed.

oc get all -l app=myapp
oc get is,bc,configmap,secret,pvc -l app=myapp

If pods are terminating for too long, inspect finalizers or dependent storage:

oc describe pod myapp-1-abcde
oc get pvc

Persistent volume claims usually need separate review. You should only remove them when you are sure the application data is no longer needed.

Common Pitfalls

• Running oc delete in the wrong project. Check oc project first, or pass -n explicitly.
• Assuming oc delete all removes image streams, build configs, config maps, secrets, or persistent volume claims. It does not cover every object type.
• Deleting by label when labels are inconsistent. Verify with oc get ... -l app=myapp before using delete.
• Removing an image stream tag and expecting the entire image stream to disappear. is/myapp:latest and is/myapp are different targets.
• Forgetting that routes and services are separate resources. Removing the deployment config alone does not delete external access.

Summary

• Use oc get first to see exactly which resources belong to the application.
• Delete individual objects by name when you want the safest, most auditable cleanup.
• Use label-based deletion only when labels are consistent across all related resources.
• Remember that oc delete all does not mean every resource in the namespace.
• Verify the result with follow-up oc get commands, especially for image streams, routes, and storage.