Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

che #18369 Deleting the common PVC if there are no workspaces left for a given user #18713

Closed
wants to merge 3 commits into from

Conversation

ibuziuk
Copy link
Member

@ibuziuk ibuziuk commented Dec 30, 2020

What does this PR do?

Deleting the common PVC if there are no workspaces left for a given user

What issues does this PR fix or reference?

#18369

How to test this PR?

image - quay.io/ibuziuk/che-server:che-18369

  • When all workspaces are removed the common PVC is also deleted
  • PVC is re-created once a new non-ephemeral workspace is started

common-PVC

PR Checklist

As the author of this Pull Request I made sure that:

Reviewers

Reviewers, please comment how you tested the PR when approving it.

Copy link
Member

@sleshchenko sleshchenko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general looks good but there are corner cases:

  1. We have different namespace strategy, one of them is common predefined, like che, then multiple users use the same PVC.
  2. Do we have a guarantee that the same PVC was not used for another purpose apart from Che?

The safe solution I see here: PVC-clean-up job apart from removing the files is able to remove PVC if there are no files left.

* Removes PVC by name.
*
* @param name the name of the PVC
* @throws InfrastructureException
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please add a few words

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there are a few words already ;-)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, you probably mean smth. like when any error occurs while removing for exeption

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

Page<WorkspaceImpl> workspaces = workspaceManager.getWorkspaces(userId, false, 30, 0);
if (workspaces.isEmpty()) {
log.debug("User '{}' has no more workspaces left", userId);
userHasNoWorkspaces = true;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally I prefer early return

private boolean userHasNoWorkspaces() {
    String userId = getSessionUserIdOrUndefined();
    if (!"undefined".equals(userId)) {
      try {
        Page<WorkspaceImpl> workspaces = workspaceManager.getWorkspaces(userId, false, 1, 0);
        if (workspaces.isEmpty()) {
          log.debug("User '{}' has no more workspaces left", userId);
          return true;
        }
      } catch (ServerException e) {
        log.error(
            "Unable to get the number of workspaces for user '{}'. Cause: {}",
            userId,
            e.getMessage(),
            e);
      }
    }
    return false;
  }

Also, I don't think you need to fetch 30 workspaces, even one should be enough.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point regarding 30, but I preferred to use the default configuration.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point regarding 30, but I preferred to use the default configuration.

Since it's not a constant but just a hard-coded value, there is no guarantee that it will continue to be a default.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right, but currently it is default on the service level, anyway changed to 1

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that is unnecessary logic. userid can be che in single-user mode or real in multi-user mode. It can't be "undefined"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose it may work in the wrong way when admin removes user and their workspaces.

@sleshchenko @sparkoo @metlos wdyt. Maybe we should iterate over all workspace and check if that is the last workspace in the concrete k8s namespace. Of cause, if there are no workspaces at all it's safe to delete pvc.

it should fix the issue above

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anonymus user will be "undefined" based on implementation.
Handling the case when the common PVC is used across multiple users ('workspaceNamespaceDefault' without placeholders is defined) - 8e02f78

@ibuziuk
Copy link
Member Author

ibuziuk commented Dec 30, 2020

We have different namespace strategy, one of them is common predefined, like che, then multiple users use the same PVC.

I'm not aware of this strategy, could you clarify how is it possible to configure a common PVC for multiple users?

Do we have a guarantee that the same PVC was not used for another purpose apart from Che?

Well, I would expect that che.infra.kubernetes.pvc.name is used explicitly for workspaces and nothing more - docs ref Defines the settings of PVC name for che workspaces

@sleshchenko
Copy link
Member

I'm not aware of this strategy, could you clarify how is it possible to configure a common PVC for multiple users?

Just deploy Che with Che Operator where workspaceNamespaceDefault has a fixed name, like workspaceNamespaceDefault(probably you also need to disable openshift oauth). It's not a production configuration but still, it's possible.

spec:
  server:
    workspaceNamespaceDefault: che

@skabashnyuk
Copy link
Contributor

skabashnyuk commented Dec 31, 2020

@sleshchenko @sparkoo @metlos wdyt. Maybe we should iterate over all workspace and check if that is the last workspace in the concrete k8s namespace. Of cause, if there are no workspaces at all - it's safe to delete pvc.

@ibuziuk
Copy link
Member Author

ibuziuk commented Dec 31, 2020

Just deploy Che with Che Operator where workspaceNamespaceDefault has a fixed name

@sleshchenko could you clarify what is the expected flow when the property is enabled. Tested with latest Che against OCP 4.6 and this setup fails with permissions issue:

Error: Failed to start the workspace: "Failure executing: POST at: https://172.30.0.1/apis/project.openshift.io/v1/projectrequests. Message: Forbidden!Configured service account doesn't have access. Service account may have been revoked. projectrequests.project.openshift.io is forbidden: User "system:serviceaccount:eclipse-che:che" cannot create resource "projectrequests" in API group "project.openshift.io" at the cluster scope. The error may be caused by an expired token or changed password. Update Che server deployment with a new token or password."

Is it expected that cluster-admin grants manually the required permissions for che SA for a namespace specified in workspaceNamespaceDefault ?

@sleshchenko
Copy link
Member

sleshchenko commented Dec 31, 2020

Is it expected that cluster-admin grants manually the required permissions for che SA for a namespace specified in workspaceNamespaceDefault ?

It's not expected and it used to work. @tolusha Do you remember the changes in that area?

BTW It works fine on minikube

@ibuziuk
Copy link
Member Author

ibuziuk commented Dec 31, 2020

Handling the case when the common PVC is used across multiple users ('workspaceNamespaceDefault' without placeholders is defined) - 8e02f78

@ibuziuk
Copy link
Member Author

ibuziuk commented Dec 31, 2020

Sonar check is failing:

Error:  Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.7.0.1746:sonar (default-cli) on project che-server: You're not authorized to run analysis. Please contact the project administrator.

any ideas on how the permissions are expected to be granted?

@skabashnyuk
Copy link
Contributor

Sonar check is failing:

That is ok for the fork.

@tolusha
Copy link
Contributor

tolusha commented Jan 4, 2021

@ibuziuk @sleshchenko
It seems the case when OpenShift OAuth is not enabled and related to that issue #15493

}

private String getSessionUserIdOrUndefined() {
final Subject subject = EnvironmentContext.getCurrent().getSubject();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this code is not needed. You always should have a valid subject.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not following, why there is an isAnonymous() method in this case?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed this method and improved the case when the subject is anonymous

@che-bot che-bot added status/code-review This issue has a pull request posted for it and is awaiting code review completion by the community. kind/enhancement A feature request - must adhere to the feature request template. labels Jan 4, 2021
Copy link
Contributor

@amisevsk amisevsk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't had a chance to test, but I did have a question: are there any issues around timing when removing the common PVC? i.e. if I delete my last workspace and then immediately try to create a new one, will a terminating claim-che-workspace PVC block workspace creation for some length of time?

I seem to recall running into issues waiting for garbage collection on PVCs in e.g. minikube, but don't know the details further than that.

@ibuziuk
Copy link
Member Author

ibuziuk commented Jan 7, 2021

That is ok for the fork.

So this is considered to be an expected setup and all the PRs would be marked as red?

@skabashnyuk
Copy link
Contributor

So this is considered to be an expected setup and all the PRs would be marked as red?

Red, but it's not mandatory.

@ibuziuk
Copy link
Member Author

ibuziuk commented Jan 7, 2021

Red, but it's not mandatory.

pretty ugly IMO ;-) Wondering how the plugin can be configured to be green for PRs (currently it is false positive)

@ibuziuk
Copy link
Member Author

ibuziuk commented Jan 7, 2021

I haven't had a chance to test, but I did have a question: are there any issues around timing when removing the common PVC? i.e. if I delete my last workspace and then immediately try to create a new one, will a terminating claim-che-workspace PVC block workspace creation for some length of time?

@amisevsk yeah, this looks like a very good corner case to handle

…ces left for a given user

Signed-off-by: Ilya Buziuk <ibuziuk@redhat.com>
…oss multiple users ('workspaceNamespaceDefault' without placeholders is defined)

Signed-off-by: Ilya Buziuk <ibuziuk@redhat.com>
Signed-off-by: Ilya Buziuk <ibuziuk@redhat.com>
@che-bot
Copy link
Contributor

che-bot commented Jan 8, 2021

❌ E2E Happy path tests failed ❗

See Details

Tested with Eclipse Che Multiuser User on K8S (minikube v1.1.1)

  • Use comment "[crw-ci-test]" to rerun happy path E2E test.
  • Use comment "[crw-ci-test --rebuild]" to re-build the images and rerun happy path E2E test.

@skabashnyuk
Copy link
Contributor

code moved to https://github.com/eclipse-che/che-server/

@che-bot
Copy link
Contributor

che-bot commented May 21, 2021

❌ E2E Happy path tests failed ❗

See Details

Tested with Eclipse Che on K8S (minikube v1.1.1)

  • Use comment "[crw-ci-test]" to rerun happy path E2E test.
  • Use comment "[crw-ci-test --rebuild]" to re-build the images and rerun happy path E2E test.

Eclipse Che QE channel: https://mattermost.eclipse.org/eclipse/channels/eclipse-che-qe

@ibuziuk
Copy link
Member Author

ibuziuk commented Jun 8, 2021

Closing in favour of eclipse-che/che-server#16

@ibuziuk ibuziuk closed this Jun 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement A feature request - must adhere to the feature request template. status/code-review This issue has a pull request posted for it and is awaiting code review completion by the community. target/branch Indicates that a PR will be merged into a branch other than master.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants