Rh-che: Workspaces are not deleted when cleaning account

Created on 11 Dec 2017  路  4Comments  路  Source: redhat-developer/rh-che

Placeholder for https://github.com/openshiftio/openshift.io/issues/1614

This is probably something that should be fixed init-tenant side but may need to involve che-starter as well.

kinbug severitP1

Most helpful comment

Now that che-maintenance service is deployed in dedicated we could use it to do the cleanup.

A new cleanWorkspaces endpoint has been implemented in the che-tenant-maintainer dsaas service, and will be available (when PR https://github.com/fabric8-services/che-tenant-maintainer/pull/14 is merged) from other dsaas services at the following URL:

http://che-tenant-maintainer:8080/cleanWorkspaces

I assume it should be called, on reset environement from the tenant sevrice.

The required request headers are:

  • X-Request-Id: the request Id of the reset environment action
  • X-Identity-Id: the identity Id of the user that triggered the reset environment action
  • X-User-Namespace: the User OSIO Che namespace
  • Authorization: the Bearer <osioToken> value, as usual

The request can be either:

  • a GET request with the following query parameters:

    • delete-all-workspaces=true

    • optionally a dry-run=true query parameter that allow simulating the cleaning process only, without removing anything for real.

  • a POST request with the same parameters as the GET request query parameters, bundled in a JSON object body like this:

    {
        "delete-all-workspaces":"true"
    }
    

    or for a dry run (simulating only):

    {
        "delete-all-workspaces":"true",
        "dry-run":"true"
    }
    

Note that, in *dry run mode, the currently-running workspaces will still be stopped, even if nothing is finally deleted.*

Remark:

This endpoint can also be used, with delete-all-workspaces=false in regular maintenance tasks to remove, in the user workspace-dedicated persistent volume, all "orphan" workspace directories that don't correspond to existing Che workspaces in the user account of the OSIO Che server (old Che 5 workspaces, etc ...).

All 4 comments

Migration pod can be triggered by init-tenant and reused to do the cleanup.

Now that che-maintenance service is deployed in dedicated we could use it to do the cleanup.

Now that che-maintenance service is deployed in dedicated we could use it to do the cleanup.

A new cleanWorkspaces endpoint has been implemented in the che-tenant-maintainer dsaas service, and will be available (when PR https://github.com/fabric8-services/che-tenant-maintainer/pull/14 is merged) from other dsaas services at the following URL:

http://che-tenant-maintainer:8080/cleanWorkspaces

I assume it should be called, on reset environement from the tenant sevrice.

The required request headers are:

  • X-Request-Id: the request Id of the reset environment action
  • X-Identity-Id: the identity Id of the user that triggered the reset environment action
  • X-User-Namespace: the User OSIO Che namespace
  • Authorization: the Bearer <osioToken> value, as usual

The request can be either:

  • a GET request with the following query parameters:

    • delete-all-workspaces=true

    • optionally a dry-run=true query parameter that allow simulating the cleaning process only, without removing anything for real.

  • a POST request with the same parameters as the GET request query parameters, bundled in a JSON object body like this:

    {
        "delete-all-workspaces":"true"
    }
    

    or for a dry run (simulating only):

    {
        "delete-all-workspaces":"true",
        "dry-run":"true"
    }
    

Note that, in *dry run mode, the currently-running workspaces will still be stopped, even if nothing is finally deleted.*

Remark:

This endpoint can also be used, with delete-all-workspaces=false in regular maintenance tasks to remove, in the user workspace-dedicated persistent volume, all "orphan" workspace directories that don't correspond to existing Che workspaces in the user account of the OSIO Che server (old Che 5 workspaces, etc ...).

cc @aslakknutsen

Was this page helpful?
0 / 5 - 0 ratings