An app with the name "app1" is deployed and then deleted. KubePlus is terminating the "app1" Namespace. But before the NS is deleted, "app1" is deployed again. KubePlus will notice that "app1" Namespace exists (it has not terminated yet) and it will try to "upgrade" the app (If NS exists, KubePlus assumes that the app is present and tries to run helm upgrade). But since the NS is terminating, the helm upgrade fails. This failure is not reflected in the app's status message. The outcome is that the app is deployed but there are 0 pods for that app.
We can address this situation by denying the app creation request if a namespace with the app name exists but is in a 'terminating' state.
The following sequence of events is possible.
An app with the name "app1" is deployed and then deleted. KubePlus is terminating the "app1" Namespace. But before the NS is deleted, "app1" is deployed again. KubePlus will notice that "app1" Namespace exists (it has not terminated yet) and it will try to "upgrade" the app (If NS exists, KubePlus assumes that the app is present and tries to run helm upgrade). But since the NS is terminating, the helm upgrade fails. This failure is not reflected in the app's status message. The outcome is that the app is deployed but there are 0 pods for that app.
We can address this situation by denying the app creation request if a namespace with the app name exists but is in a 'terminating' state.