chectl commands in the devworkspace land

[tolusha]

Is your task related to a problem? Please describe

When devworkspace is enabled by default then some workspace commands won't work.
We have to decided what to do with them

command(s)	status	plan
auth	broken	drop
cacert	work	keep
dashboard	work	keep
devfile	broken	dropped
server:backup	broken	fixed
server:restore	broken	to fix
server:update	work	keep
server:debug	work	keep
server:delete	work	keep
server:deploy	work	keep
server:logs	not complete	to fix
server:start	work	keep
server:status	work	keep
server:stop	work	keep
server:update	work	keep
all workspace commands	broken	drop

Describe the solution you'd like

Make a plan for every not working command with devworkspace engine either to remove or fix.

Describe alternatives you've considered

No response

Additional context

#20010

[tolusha]

Issue to close: #13785

[dmytro-ndp]

@tolusha: our Happy path tests and CRW E2E tests are widely using next workspace commands [1]:

• workspace:start
• workspace:stop
• workspace:delete
• workspace:list

So, could you continue supporting those commands from chectl?

[1] https://gitlab.cee.redhat.com/codeready-workspaces/crw-jenkins/-/blob/master/vars/crwctlUtil.groovy

[tolusha]

auth and workspace commands doesn't work with devworkspace.
We can keep them for a while (for testing purpose) and then remove anyway.
Deploy and QE team will have to adjust their tests not to use those commands

[tolusha]

Droping chectl commands will be done here [1]

[1] #20866

[kpiwko]

@tolusha based on #20010 exploration, do you happen to know what is the feature parity in between chectl and k8 APIs?

[tolusha]

Hello
@kpiwko

chectl is different tool than kubectl.
It is uses to deploy Eclipse Che but kubectl is used to interact with k8s cluster.

[kpiwko]

I get that @tolusha, thanks. My point was whether to-be-removed functionality of chectl can be replace with kubectl. It is essential that any changes won't cause some functionality to be available only through UI, as this causes significant overhead during testing.

An ask to replace used chectl functionality in in the test suites because of removing functionality there is valid and just needs to be accounted in efforts to deliver these changes in chectl. However if such changes would require using UI to test Che, it is a no-go and this task should be updated to cover that gap.

cc @dmytro-ndp @rhopp

[rhopp]

What I think would help us greatly is to have an instructions on how to create/start/list workspaces using "any" API.
I have rough idea how to do that, but I'm still missing some pieces of the puzzle. And please correct me if I'm wrong on anything
For listing workspaces & their state we can use k8s api and query for DevWorkspace CR's.
For creation & operatrions on workspaces (start,stop, ...), we could use k8s api to create/edit DevWorkspace CRs to create/edit workspace, but we need to create the workspace from Devfile.
So what I'm missing right now is some clear instructions on how to convert Devfile(v2) to DevWorkspace. Florent already pointed me to code, which is doing such conversion. But even though it's not very complicated - it's also not trivial. Maybe we could have this functionality exposed as a API on dashboard? (or... maybe it already is, I just don't know about it?)
@dmytro-ndp Do we need anything else?

[tolusha]

@akurinnoy
Could you help us with k8s API requests to create/start/stop/list devfile 2.0 workspaces?

[benoitf]

for stop (and also start again): https://github.com/eclipse-che/che-theia/blob/8a48c2fbd803e0c37548cd4720cdd7282a13b3a6/extensions/eclipse-che-theia-remote-impl-k8s/src/node/k8s-workspace-service-impl.ts#L90-L120 (update of .spec.started field)

[nickboldt]

For the simplest case of create the workspace from Devfile -- could we not curl the factory URL and have that flow create the workspace? That way we're testing an actually recommended customer user story and might discover problems w/ passing parameters or page refresh bugs...

For the other commands like stop, delete and list I would expect there are simple oc or even odo commands we use.

[l0rd]

An alternative to @nickboldt proposal to use an HTTP request to start the workspace (that can be complicated if devfile->devworkspace conversion is still done client side cc @benoitf @olexii4) is to use the DW CRs included in Che devfile registry.

Create the workspaces namespace (optional)

This step is required if the Che user hasn't logged in yet. The first time a user open the User Dashboard, a namespace with some particular annotations/labels is created. So if this namespace doesn't exist it should be created:

CHE_USER_NAME="kube:admin"
CHE_USER_NAMESPACE="che-workspaces"
kubectl apply - <<EOF
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    che.eclipse.org/username: "${CHE_USER_NAME}"
  labels:
    app.kubernetes.io/component: workspaces-namespace"
    app.kubernetes.io/part-of: che.eclipse.org
  name: ${CHE_USER_NAMESPACE}"
EOF

Start a workspace

⚠️ UPDATE2: the following command doesn't work out of the box, the devworkspacerouting needs to be patched. I need to find an easy way to do that or open a specific issue to make this scenario easier to run for QE. I updated the instructions to start the workspace via command line. Note that today the dashboard injects a user kubeconfig in the workspace containers too (PR) and the following commands don't do that (although it should be easy to do that via command line too.)

REGISTRY_URL="https://eclipse-che.github.io/che-devfile-registry/main"
CHE_SAMPLE="nodejs"
CHE_EDITOR="che-theia-next"
DW="nodejs-web-app"
DWT="theia-ide-${DW}"

# Set the namespace to be CHE_USER_NAMESPACE
CHE_USER_NAMESPACE="che-workspaces"
kubens "${CHE_USER_NAMESPACE}"

# Create the editor DevWorkspaceTemplate
curl -sSL ${REGISTRY_URL}/devfiles/${CHE_SAMPLE}/devworkspace-${CHE_EDITOR}.yaml | yq --arg DWT ${DWT} 'select(.metadata.name == $DWT)' | kubectl apply -f -

# Create the DevWorkspace itself
curl -sSL ${REGISTRY_URL}/devfiles/${CHE_SAMPLE}/devworkspace-${CHE_EDITOR}.yaml | yq --arg DW ${DW} 'select(.metadata.name == $DW)' | jq '. * {spec: {routingClass: "che"}}' | kubectl apply -f -

# Wait until it's started
k wait --for=jsonpath='{.status.phase}'=Running dw/${DW} --timeout=-1s

List workspaces

k get dw 

Stop an existing workspace

k patch dw ${DW} -p '{"spec":{"started":false}}' --type=merge
k wait --for=jsonpath='{.status.phase}'=Stopped dw/${DW}

Restart an existing workspace

k patch dw ${DW} -p '{"spec":{"started":true}}' --type=merge
k wait --for=jsonpath='{.status.phase}'=Running dw/${DW}

[kpiwko]

Thank you @benoitf @l0rd @nickboldt . @dmytro-ndp would it meet team needs once devworkspacerouting is patched?

[dmytro-ndp]

@kpiwko: thanks for heads up.
Hope, @l0rd will find an easy way or open a specific issue to make suggested scenarios easier to run in E2E tests.

@l0rd, @benoitf , @nickboldt: thank you for help!

[benoitf]

I think that if you're adding .spec.routingClass: che on the prebuilt devWorkspace yaml it should work

...
spec:
  ....
  routingClass: che
...  

[benoitf]

moving issue to 7.42 milestone as this issue is part of the endgame

[l0rd]

@dmytro-ndp I have update the instructions to start a workspace