[UD] Devworkspaces renaming

[akurinnoy]

Is your enhancement related to a problem? Please describe.

The name of resources in K8s is immutable, which means we won't be able to rename workspaces if we use devworkspace engine.

Describe the solution you'd like

So, we could work around it if we introduce a dedicated annotation for the display name, also we may want to have a description (it's kind of official way since OpenShift Console uses it for the projects stuff):

kind: Project
apiVersion: project.openshift.io/v1
metadata:
  name: test
  annotations:
    openshift.io/description: Just test description
    openshift.io/display-name: It's my test namespace

Describe alternatives you've considered

Don't allow users to rename devworkspaces.

Additional context

https://github.com/eclipse/che-dashboard/pull/209 makes the Overview tab read-only for devworkspaces.

[sleshchenko]

Updating the description after figuring out K8s object names are immutable.

[amisevsk]

Another thing to note here: we may have to be careful in how we handle naming if we use the a displayname annotation. For example, if I create a DevWorkspace named golang, and then rename it to golang-specific-issue, the DevWorkspace resource is still named golang. This means that though the UI will show no workspaces named golang, creating a new workspace with name golang will fail due to name conflict.

We can work around this by either

1. Using randomly generated metadata.name in CRs and always using a displayname (which has the downside of confusing resources in your namespace -- which workspace-xxxxx-xxxxx dw is the one I'm looking for?)
   • We could be a little smart here and by default append random characters to new workspace names to make this a little better
2. Resolving those collisions manually (if a DevWorkspace named my-devworkspace exists, detect this and instead create my-devworkspace-1).

Both of these options have downsides and edge cases to deal with, so I lean towards not allowing DevWorkspace renames.

[che-bot]

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.

[amisevsk]

/remove-lifecycle stale

[nickboldt]

Note that this is a regression from pre-DW versions of Che, as I can still rename my workspaces as I edit my devfile in 2.15. Alas with 3.0, that'll break and I expect we'll get some user feedback about it :(

[nickboldt]

An easy workaround for "I can't open the same devfile multiple times" eg., in order to make changes to one and compare to another (perhaps to see if my devfile will compile with BOTH JDK 8 and 11 in separate workspaces from the same devfile source): append ?new on the factory URL:

https://che-dogfooding.apps.che-dev.x6e0.p1.openshiftapps.com/#https://github.com/che-samples/java-spring-petclinic/tree/devfilev2?new

green: created w/o a ?new suffix red: created w/ a ?new suffix

[che-bot]

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.