Rh-che: Need to verify that existing DELETE /api/user works as expected on che.openshift.io and does the hard delete of all the existing info about a user

[ibuziuk]

Che should provide API to clean up users when they are being deactivated (to shutdown WSs if needed, etc). Possible implementation - Che admin user with the ability to remove other non-admin users in Che server / or user that can remove himself:

/api/user

@DELETE @Path("/{id}") @GenerateLink(rel = LINK_REL_USER) @ApiOperation("Delete user") @ApiResponses({ @ApiResponse(code = 204, message = "User successfully removed"), @ApiResponse( code = 409, message = "Couldn't remove user due to conflict(e.g. it has related entities)"), @ApiResponse(code = 500, message = "Couldn't remove user due to internal server error") }) public void remove(@ApiParam("User identifier") @PathParam("id") String id) throws ServerException, ConflictException {userManager.remove(id); }

https://docs.google.com/document/d/1vbn6l7ebXeRvBpMgfbrsOdZwMVpiVZvuxwMgOul3-Ww/edit

[skabashnyuk]

What is the difference between proposed and existed https://github.com/eclipse/che/blob/master/wsmaster/che-core-api-user/src/main/java/org/eclipse/che/api/user/server/UserService.java#L200-L214 ?

[ibuziuk]

@skabashnyuk it's just basically to verify that everything works as expected on che.openshift.io
Am I correct that [1] does hard delete, with all the db cleanup?

[1] https://github.com/eclipse/che/blob/master/wsmaster/che-core-api-user/src/main/java/org/eclipse/che/api/user/server/UserService.java#L200-L214

[skabashnyuk]

Am I correct that [1] does hard delete, with all the db cleanup?

Yes. With a requirement that all workspaces have to be stopped before the delete request.

[ibuziuk]

@skabashnyuk so, DELETE /api/user will not stop running workspaces and stopping should be explicitly executed beforehand?

[skabashnyuk]

will not stop running workspaces and stopping should be explicitly executed beforehand

yes.

[ibuziuk]

@alexeykazakov could you please clarify how/when the DELETE API is going to be called? Am I correct that it will be somehow involved from auth de-provisioning logic? if yes, when auth treat user as the one who needs to be de-provisioned / removed?

[alexeykazakov]

Yes, it's part of user deactivation flow.
If auth service doesn't receive any requests with the user token (login, logout, token refresh, user info, etc) for the 31 days in a raw then such a user is treated as inactive. All inactive users are deprovisioned daily (maybe hourly):

• User is marked as deprovisioned in manage.openshift.com
• User is deleted from auth.openshift.io
• Che is called to delete the user/workspaces - This issue
• Namespaces deleted in tenant service

If user later wants to come back, the login flow will basically initiate re-registering/re-creating the user in OSIO with the same username/email/RHD credentials.

[amisevsk]

So it seems like we just have to account for the "stop all workspaces" in case any are running.

[ibuziuk]

@amisevsk I do not think we should call 'stop all workspaces' since according to the flow @alexeykazakov described there can not be any running workspaces. If there is one we have an issue on our end that should be reported and fixed. Basically, from Che perspective, this means that user is deleted only when he had no running workspaces for more than 30 days. Does it make sense?

[ibuziuk]

Che is called to delete the user/workspaces - This issue

DELETE https://che.openshift.io/api/user/<identity_id>
Authorization:  Bearer <OSIO_USER _TOKEN>

tested locally - calling this API does hard removal of the user (user is removed from dedicated db table completely)

@alexeykazakov are you ok to close the issue?

[amisevsk]

@ibuziuk I'd mostly be concerned because we have had issues of workspaces stuck in STARTING or STOPPING phases in the past. One of those could potentially persist for a month after a user uses the workspace.

[alexeykazakov]

Yes, we will call that endpoint when there is no activity from the user for 31 days but even if you have some stuck workspaces they will be deleted because we also call the tenant service during deactivation to delete all the namespaces.
I'm more worried about the internal state of the che master. DB, etc.
If you are saying that

DELETE https://che.openshift.io/api/user/<identity_id>
Authorization:  Bearer <OSIO_USER _TOKEN>

should do the all needed cleanup in the che master side then fine. I think we can close this issue.
cc: @xcoulon

[ibuziuk]

@alexeykazakov please, just make sure that you call DELETE https://che.openshift.io/api/user/<identity_id> before namespaces removal on tenant side. If the DELETE call is failing for some reason, namespaces should not be removed and Che OSIO team should be involved for analysis

[alexeykazakov]

If the DELETE call is failing for some reason, namespaces should not be removed and Che OSIO team should be involved for analysis

Ack. Will do.

[xcoulon]

@alexeykazakov please, just make sure that you call DELETE https://che.openshift.io/api/user/<identity_id> before namespaces removal on tenant side. If the DELETE call is failing for some reason, namespaces should not be removed and Che OSIO team should be involved for analysis

@ibuziuk should we expect a 200 OK response after the DELETE https://che.openshift.io/api/user/<identity_id> ?

[ibuziuk]

@xcoulon yes, I think so, but let me check

[xcoulon]

@xcoulon yes, I think so, but let me check

@ibuziuk also, is it a blocking endpoint? I mean: once the response returns, can we immediately process with the tenant deletions?

[ibuziuk]

yeah, it is sync / blocking AFAIK - once 200 is returned db records are removed cc @skabashnyuk

[xcoulon]

ok, great! thanks for confirming, @ibuziuk 🙌

[ibuziuk]

@xcoulon most welcome, just please bear in mind this part while integration - https://github.com/redhat-developer/rh-che/issues/1297#issuecomment-480356148

@alexeykazakov please, just make sure that you call DELETE https://che.openshift.io/api/user/ before namespaces removal on tenant side. If the DELETE call is failing for some reason, namespaces should NOT be removed and Che OSIO team should be involved for analysis

[xcoulon]

@xcoulon most welcome, just please bear in mind this part while integration - #1297 (comment)

@alexeykazakov please, just make sure that you call DELETE https://che.openshift.io/api/user/ _before_ namespaces removal on tenant side. If the DELETE call is failing for some reason, namespaces should NOT be removed and Che OSIO team should be involved for analysis

yes, I've planned to call Che before the tenant service, and only the latter if Che responded with 200 OK ;)

[ibuziuk]

@xcoulon @alexeykazakov did some last checks:

• if a user has running workspaces removal will fail with 500 (technically should never happen during auth deprovisioning flow. If it happens this means there is a bug on Che side):

{
"message": "The workspace 'workspace_id' is currently running and cannot be removed."
}

• if removal is successful 204 No Content is returned (NOT 200 OK!)
• if a token is expired 401 unauthorized will be returned The specified token is expired

[xcoulon]

@ibuziuk thanks for the update. I will treat all non 204 responses as errors and log the responses.