Undeploying & Redeploying a project always raises an error the first time

Description

Summary
Let's say you already have an existing project running on an APA instance.

If you want to redeploy a new version of this one undeploying the previous one then you have to :

  • Undeploy the running "application instance"

  • Delete the deployment descriptor

  • Deploy the new version from the "Project Releases" menu

During the final step, when you choose to deploy the new version, an error is always raised expliciting that "a deployment descriptor with that name already exists"... If you try again, the error disappeared and the new version is deployed 

 

Steps to reproduce

1. Create a new project on APA

2. Deploy it once through the Admin app

3. Undeploy it through the 3 steps mentioned earlier in the Summary

4. Redeploy your project -> The error expliciting that "a deployment descriptor with that name already exists" is then displayed and the project is not deployed.

5. Try to redeploy again your project -> This time, everything works perfectly and the project is now redeployed

 

Expected behaviour
After undeploying a project through the Admin app, you should still have the possibilty to redeploy this project (same or new version) without error.

Current behaviour
After undeploying a project, you always get an error the first time you try to redeploy it 

 

ACs:

  • When deleting the descriptor, after undeploying the application, in case the kubernetes namespace is still being removed (along with all the resources), the API should return an HTTP 409 conflict status with message of “Cannot delete descriptor, descriptor still being removed.” or similar.

  • In the front-end, this message should be displayed as a notification (how other error messages are also).

Environment

APA M10

Testcase ID

None

Activity

Show:
Swetha Balasubramaniam
January 26, 2021, 5:06 PM

Verified.

  • After undeploying a project in Admin app and deleting the descriptor, able to redeploy the project from project releases without any error.

  • When we delete descriptor before the deployment in kubernetes is removed, it returns 409 with the following message: "We hit a problem deleting the descriptor. Try deleting it again."

Francesco Fazzini
December 7, 2020, 11:10 AM

Decreasing to Cat 3, will be merged anyway in few days right after WD release.

We can’t merge this during regression, as can cause side effects.

Zoltan Palfi
November 30, 2020, 4:41 PM

Okay, great! Just confirming that the FE error message when namespace is not removed yet and we attempt to delete the deployment descriptor will be then

"We hit a problem deleting the descriptor. Try deleting it again."

Francesco Fazzini
November 30, 2020, 3:50 PM
Edited

there is not a delete status for an application . That would be more complex solution to implement.

We were following what you suggested preventing to delete a descriptor (which now it is allowed) until the application is not fully removed asynchronously in k8s.

“an’t we delete the deployment descriptor line in the UI only when all the stuff is removed from Kubernetes ?“

So you will need to click again to the delete descriptor button in case you get that error message.

Is that ok?

Zoltan Palfi
November 30, 2020, 3:14 PM

Hi ,

 

We need to add a new error message to the front-end when we try to delete the descriptor but the namespace resource still exists. I would suggests something along the lines of existing error messages, so on the front-end:

"We hit a problem deleting the descriptor. Try deleting it again."

and on the API layer, we should go with 409 Conflict with error message of

"Cannot delete descriptor, application still being deleted: {{descriptorId}}. Please try again shortly."

CC:

Flagged
Fixed

Assignee

Swetha Balasubramaniam

Reporter

Massis Buyukkalender

Labels

None

Premier Customer

None

Security Issue

None

Target Platform

None

Code Branch

None

Build Location

None

Regression Since

None

Work Funnel End

None

Patch Attached

None

Dependent Version/s

None

Cloud or Enterprise

None

Prioritization Score

None

Delivery Team

Team 2

Bug Priority

Category 3

Sprint

None

Fix versions

Affects versions