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

Cannot create workspace from Custom devfile when using namespace placeholder like <workspaceid>-che #17656

Closed
4 of 22 tasks
guydog28 opened this issue Aug 18, 2020 · 3 comments
Closed
4 of 22 tasks
Labels
area/che-server kind/bug Outline of a bug - must adhere to the bug report template. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. severity/P1 Has a major impact to usage or development of the system.

Comments

@guydog28
Copy link

guydog28 commented Aug 18, 2020

Describe the bug

It seems, when using placeholders to create workspaces in new namespaces, that the system attempts to validate the namespace name literally, without replacing the placeholder text. So a namespace like <workspaceid>-che will not even attempt to be created. Creating a workspace with the exact same devfile into the same namespace works if the devfile is added to the devfile registry and is create by clicking the item in the Getting Started pane.

Che version

  • latest
  • nightly
  • other: please specify

Steps to reproduce

Expected behavior

Runtime

  • kubernetes (include output of kubectl version)
  • Openshift (include output of oc version)
  • minikube (include output of minikube version and kubectl version)
  • minishift (include output of minishift version and oc version)
  • docker-desktop + K8S (include output of docker version and kubectl version)
  • other: (please specify)

Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2-0-g52c56ce", GitCommit:"b66f2d3", GitTreeState:"clean", BuildDate:"2020-08-11T15:26:36Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.6", GitCommit:"dff82dc0de47299ab66c83c626e08b245ab19037", GitTreeState:"clean", BuildDate:"2020-07-15T16:51:04Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}

Screenshots

image

Installation method

  • chectl
    • using operator installer
    • provide an output of chectl version: chectl/7.17.0 darwin-x64 node-v10.22.0
  • OperatorHub
  • I don't know

Environment

  • my computer
    • Windows
    • Linux
    • macOS
  • Cloud
    • Amazon
    • Azure
    • GCE
    • other (please specify)
  • other: please specify

Eclipse Che Logs

Additional context

This can be worked around by adding the devfile to the devfile registry, and clicking it from getting started, which seems to bypass this erroneous check and create the generated namespace. However the workspace will not start still, due to #17631

@guydog28 guydog28 added the kind/bug Outline of a bug - must adhere to the bug report template. label Aug 18, 2020
@che-bot che-bot added the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Aug 18, 2020
@metlos metlos added area/che-server severity/P1 Has a major impact to usage or development of the system. and removed status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. labels Aug 19, 2020
@guydog28
Copy link
Author

Any updates here? It looks like 17631 was resolved for 7.19.0, but this one causes just as much harm, as it is not possible to create a workspace from a devfile, you can only click a Stack from Getting Started.

@guydog28
Copy link
Author

guydog28 commented Nov 6, 2020

As of 7.21.0, this is still an issue. Any updates? It appears to have changed now, that it now generates a proper workspace name, but the error is that custom namespaces are not allowed (which is by design) but this is not technically a custom namespace - it is generated as expected.

image

@che-bot
Copy link
Contributor

che-bot commented May 18, 2021

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

@che-bot che-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label May 18, 2021
@che-bot che-bot closed this as completed Jun 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/che-server kind/bug Outline of a bug - must adhere to the bug report template. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. severity/P1 Has a major impact to usage or development of the system.
Projects
None yet
Development

No branches or pull requests

3 participants