Closed nils-mosbach closed 2 years ago
@nils-mosbach thank you for the report. Could you provide more details on how Che was deployed (which exact command was used)?
I've just tried to deploy nightly Che on minikube and start react sample app - it worked for me (including deletion of the workspace).
Sure. If you want me to try something or dig deeper, please let me know. We're running a rancher provisioned bare metal cluster with three nodes. Storage is handled by Linstor/Linbit which is basically a DRBD replication between nodes. We haven't had troubles with access rights on v1 devfiles or any other application so far. Wildcard SSL certificates that we use for all developer services are issued by a trusted authority.
chectl server:deploy \
--installer=operator \
--chenamespace=dev-studio \
--domain=studio.company.dev \
--multiuser \
--platform=k8s \
--deployment-name=dev-studio \
--skip-kubernetes-health-check \
--che-operator-cr-patch-yaml=./operator-config.yaml \
--batch
spec:
devWorkspace:
enable: true
server:
tlsSupport: true
customCheProperties:
CHE_LIMITS_USER_WORKSPACES_RUN_COUNT: "-1"
CHE_LIMITS_WORKSPACE_IDLE_TIMEOUT: "9000000"
CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT: "dev-studio-workspace-<username>"
CHE_INTEGRATION_GITLAB_SERVER__ENDPOINTS: "https://git.company.dev"
CHE_INTEGRATION_GITLAB_OAUTH__ENDPOINT: "https://git.company.dev/"
cheImagePullPolicy: Always
devfileRegistryPullPolicy: Always
pluginRegistryPullPolicy: Always
database:
externalDb: false
postgresImagePullPolicy: Always
storage:
pvcStrategy: per-workspace
pvcClaimSize: '5Gi'
auth:
externalIdentityProvider: true
identityProviderURL: 'https://auth.company.dev/auth'
identityProviderRealm: 'git-dev'
identityProviderClientId: 'dev-studio'
openShiftoAuth: false
k8s:
ingressDomain: 'studio.company.dev'
ingressStrategy: 'single-host'
tlsSecretName: 'tls-dev-studio'
Hi @nils-mosbach!
I suspect this issue has the same underlying cause as https://github.com/eclipse/che/issues/20965. Bare metal clusters have caused issues in the past due to how storage permissions are handled. A first (and relatively easy) step in debugging is inspecting the claim-devworkspace
PVC as in https://github.com/eclipse/che/issues/20965#issuecomment-999687091. With that info I can start looking into it more deeply.
Great thanks a lot! :)
As mentioned in https://github.com/eclipse/che/issues/20965#issuecomment-1000187110 setting fsGroup on workspace deployments solves the issue.
PR https://github.com/devfile/devworkspace-operator/pull/748 is open now, which sets fsGroup
to match runAsUser
by default. This should resolve this issue once it works its way into a release.
Next branch of the devworkspace operator solves the issue in my case. Thanks!
Describe the bug
When I try to start a devfile 2 using Che 7.40.2 / DevWorkspaces enabled the loading screen of theia keeps hanging.
Chrome Debug console displays the following errors:
Any Idea whats wrong?
Che version
7.40@latest
Steps to reproduce
Start a new Workspace from a devfile v2.
Expected behavior
Theia opens as expected.
Runtime
Kubernetes (vanilla)
Screenshots
Browser Logs
Installation method
chectl/latest
Environment
Linux
Eclipse Che Logs
Additional context
Just in case I fetched environment variables passed to theia.
Devfile v2 provisioned workspace (doesn't start)
devfile v1 provisioned workspace (does start)
devfile
The devfile we used for gen 2 test.