Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Final output on workspace creation shows "connecting" forever - confusing UX #1036

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

Closed
Tracked by #1939
f0ssel opened this issue Apr 15, 2022 · 15 comments · Fixed by #2155
Closed
Tracked by #1939

Final output on workspace creation shows "connecting" forever - confusing UX #1036

f0ssel opened this issue Apr 15, 2022 · 15 comments · Fixed by #2155
Assignees
Labels
api Area: HTTP API docs Area: coder.com/docs
Milestone

Comments

@f0ssel
Copy link
Contributor

f0ssel commented Apr 15, 2022

der-developer-f0ssel]
  Apply complete! Resources: 3 added, 0 changed, 0 destroyed.
  Outputs: 0
✔ Starting workspace [30901ms]
✔ Cleaning Up [0ms]
┌────────────────────────────────────────────────────────────────────┐
│ RESOURCE                     STATUS             ACCESS             │
├────────────────────────────────────────────────────────────────────┤
│ google_compute_disk.root     ephemeral                             │
├────────────────────────────────────────────────────────────────────┤
│ google_compute_instance.dev  ephemeral                             │
│ └─ dev (linux, amd64)        ⦾ connecting [0s]   coder ssh f0ssel  │
└────────────────────────────────────────────────────────────────────┘
The f0ssel workspace has been created!

We should probably make it clear that we aren't waiting here, since it seems like the CLI is going to wait for the "connecting" to change to "connected".

@f0ssel f0ssel added bug 🐛 docs Area: coder.com/docs labels Apr 15, 2022
@f0ssel f0ssel changed the title Bug: Bug: final output on workspace creation shows "connecting" forever - confusing UX Apr 15, 2022
@ammario ammario added this to the V2 Beta milestone May 4, 2022
@misskniss
Copy link

@tjcran We have already done grooming for this sprint (last sprint of Beta) is this an intentional injection or can this move to Community MVP?

@misskniss
Copy link

@kylecarbs I added you to poker planning for this but there may be others you want to add. I am just assuming that this fix will be you.

@tjcran tjcran modified the milestones: V2 Beta, Community MVP May 5, 2022
@spikecurtis
Copy link
Contributor

I'm not able to repro on version Coder v0.5.2-devel+568574c with docker-local template. @f0ssel if you're still able to repro, can you give some more details, i.e. the template you are using?

> Confirm create? (yes/no) yes
✔ Queued [154ms]
✔ Setting up [1ms]
⧗  Starting workspace 
  Terraform 1.1.9
  coder_agent.dev: Plan to create
  docker_volume.coder_volume: Plan to create
  docker_container.workspace[0]: Plan to create
  Plan: 3 to add, 0 to change, 0 to destroy.
  docker_volume.coder_volume: Creating...
  coder_agent.dev: Creating...
  coder_agent.dev: Creation complete after 0s [id=026f074f-38ab-4b6f-91b5-10bea2692467]
  docker_volume.coder_volume: Creation complete after 0s [id=coder-developer-test00-root]
  docker_container.workspace[0]: Creating...
  docker_container.workspace[0]: Still creating... [10s elapsed]
  docker_container.workspace[0]: Still creating... [20s elapsed]
  docker_container.workspace[0]: Still creating... [30s elapsed]
  docker_container.workspace[0]: Still creating... [40s elapsed]
  docker_container.workspace[0]: Creation complete after 49s [id=38c47ecb7bcd8677f66bd2ae6c0569fb9c8b00dc4c01d3ac4922e79af5c7baaf]
  Apply complete! Resources: 3 added, 0 changed, 0 destroyed.
  Outputs: 0
✔ Starting workspace [51204ms]
✔ Cleaning Up [0ms]
┌─────────────────────────────────────────────────────────────┐
│ RESOURCE                    STATUS       ACCESS             │
├─────────────────────────────────────────────────────────────┤
│ docker_container.workspace  ephemeral                       │
│ └─ dev (linux, amd64)       ⦿ connected   coder ssh test00  │
├─────────────────────────────────────────────────────────────┤
│ docker_volume.coder_volume  ephemeral                       │
└─────────────────────────────────────────────────────────────┘
The test00 workspace has been created!

@misskniss misskniss mentioned this issue May 6, 2022
16 tasks
@tjcran
Copy link

tjcran commented May 7, 2022

Because this is a "confusing UX" item and also not consistently reproduced, I am removing this as a switch blocker. If @f0ssel confirms it is no longer happening for him, it should be closed.

@misskniss
Copy link

@mafredri can you add details here for what you see when the command completes but the connecting state does not ever change?

@mafredri
Copy link
Member

Here's how I've reproduced the original issue (latest main at the time of writing):

Start the server:

❯ ./coder --version
Coder v0.0.0-devel+841b792 Tue May 17 15:36:03 UTC 2022
https://github.com/coder/coder/commit/841b792e8ec1f4ba2252881b9d0c9ab0aeb228e7

❯ ./coder server --dev --address 0.0.0.0:7080 --access-url http://0.0.0.0:3000

On the CLI side:

❯ ./coder login http://localhost:7080

❯ ./coder templates create -d examples/docker-local

❯ ./coder create --template=docker-local my-test

image

Here the coder create doesn't wait for connecting to change to connected. It exits almost immediately with zero exit code.

Logs

`./coder templates create -d examples/docker-local`
> Create and upload "examples/docker-local"? (yes/no)
✔ Queued [291ms]
✔ Setting up [3ms]
✔ Parse parameters [11ms]
⧗  Detecting persistent resources
  Terraform 1.1.9
  coder_agent.dev: Plan to create
  docker_volume.coder_volume: Plan to create
  docker_container.workspace[0]: Plan to create
  Plan: 3 to add, 0 to change, 0 to destroy.
✔ Detecting persistent resources [8887ms]
⧗  Detecting ephemeral resources
  Terraform 1.1.9
  coder_agent.dev: Plan to create
  docker_volume.coder_volume: Plan to create
  Plan: 2 to add, 0 to change, 0 to destroy.
✔ Detecting ephemeral resources [2156ms]
✔ Cleaning Up [0ms]
┌──────────────────────────────────────────┐
│ Template Preview                         │
├──────────────────────────────────────────┤
│ RESOURCE                    STATUS       │
├──────────────────────────────────────────┤
│ docker_container.workspace  persistent   │
│ └─ dev (linux, amd64)                    │
├──────────────────────────────────────────┤
│ docker_volume.coder_volume  persistent   │
└──────────────────────────────────────────┘
> Confirm create? (yes/no)

The docker-local template has been created! Developers can
provision a workspace with this template using:

   coder create --template="docker-local" [workspace name]

`./coder server --dev --address 0.0.0.0:7080 --access-url http://0.0.0.0:3000`
2022-05-17 17:19:23.526 [INFO]	<provisionerd.go:238>	acquired job	{"initiator_username": "developer", "provisioner": "terraform", "id": "69f2b552-b869-465c-a9dc-4cad1c3c4659"}
2022-05-17 17:19:23.529 [INFO]	<provisionerd.go:352>	unpacking template source archive	{"size_bytes": 3072}
2022-05-17 17:19:23.539 [INFO]	<provisionerd.go:592>	parse complete	{"parameter_schemas": [{"name": "docker_image", "description": "What docker image would you like to use for your workspace?", "default_source": {"value": "codercom/enterprise-base:ubuntu"}, "allow_override_source": true, "default_destination": {"scheme": 1}, "redisplay_value": true, "validation_type_system": 1, "validation_error": "Invalid Docker Image!", "validation_condition": "contains([\"codercom/enterprise-base:ubuntu\", \"codercom/enterprise-node:ubuntu\", \"codercom/enterprise-intellij:ubuntu\"], var.docker_image)"}]}
2022-05-17 17:19:32.427 [INFO]	<provisionerd.go:666>	parse dry-run provision successful	{"resource_count": 2, "resources": [{"name": "workspace", "type": "docker_container", "agents": [{"name": "dev", "operating_system": "linux", "architecture": "amd64", "Auth": {"Token": ""}}]}, {"name": "coder_volume", "type": "docker_volume"}], "state_length": 0}
2022-05-17 17:19:34.531 [INFO]	<provisionerd.go:666>	parse dry-run provision successful	{"resource_count": 2, "resources": [{"name": "workspace", "type": "docker_container", "agents": [{"name": "dev", "operating_system": "linux", "architecture": "amd64", "Auth": {"Token": ""}}]}, {"name": "coder_volume", "type": "docker_volume"}], "state_length": 0}
2022-05-17 17:19:34.583 [INFO]	(coderd.provisionerd-agitated_mcnulty4)	<provisionerdaemons.go:512>	inserting template import job resource	{"job_id": "69f2b552-b869-465c-a9dc-4cad1c3c4659", "resource_name": "workspace", "resource_type": "docker_container", "transition": "stop"}
2022-05-17 17:19:34.584 [INFO]	(coderd.provisionerd-agitated_mcnulty4)	<provisionerdaemons.go:512>	inserting template import job resource	{"job_id": "69f2b552-b869-465c-a9dc-4cad1c3c4659", "resource_name": "coder_volume", "resource_type": "docker_volume", "transition": "stop"}
2022-05-17 17:19:34.584 [INFO]	(coderd.provisionerd-agitated_mcnulty4)	<provisionerdaemons.go:512>	inserting template import job resource	{"job_id": "69f2b552-b869-465c-a9dc-4cad1c3c4659", "resource_name": "workspace", "resource_type": "docker_container", "transition": "start"}
2022-05-17 17:19:34.584 [INFO]	(coderd.provisionerd-agitated_mcnulty4)	<provisionerdaemons.go:512>	inserting template import job resource	{"job_id": "69f2b552-b869-465c-a9dc-4cad1c3c4659", "resource_name": "coder_volume", "resource_type": "docker_volume", "transition": "start"}
2022-05-17 17:19:34.585 [INFO]	<provisionerd.go:449>	completed job	{"id": "69f2b552-b869-465c-a9dc-4cad1c3c4659"}
2022-05-17 17:19:58.526 [INFO]	<provisionerd.go:238>	acquired job	{"initiator_username": "developer", "provisioner": "terraform", "id": "85f185c2-54e5-436a-a83e-693d0aa24efa"}
2022-05-17 17:19:58.527 [INFO]	<provisionerd.go:352>	unpacking template source archive	{"size_bytes": 3072}
2022-05-17 17:20:05.474 [INFO]	<provisionerd.go:796>	provision successful; marked job as complete	{"resource_count": 2, "resources": [{"name": "workspace", "type": "docker_container", "agents": [{"id": "b597b88d-836a-456d-ba4b-049ffa7925ae", "name": "dev", "operating_system": "linux", "architecture": "amd64", "Auth": {"Token": "bfcc3cc4-6e3c-4bae-84a3-a917770e4d23"}}]}, {"name": "coder_volume", "type": "docker_volume"}], "state_length": 6428}
2022-05-17 17:20:05.475 [INFO]	<provisionerd.go:449>	completed job	{"id": "85f185c2-54e5-436a-a83e-693d0aa24efa"}
2022-05-17 17:20:05.954 [INFO]	(coderd)	<workspaceagents.go:244>	accepting agent	{"resource": {"id": "fd3fed32-14b9-4b2f-b61f-e40f4392fa2d", "created_at": "2022-05-17T17:20:05.474518Z", "job_id": "85f185c2-54e5-436a-a83e-693d0aa24efa", "transition": "start", "type": "docker_container", "name": "workspace"}, "agent": {"id": "6648df0a-ff2f-4bea-8ac8-6698c707cf62", "created_at": "2022-05-17T17:20:05.474528Z", "updated_at": "2022-05-17T17:20:05.474528Z", "name": "dev", "first_connected_at": {"Time": "0001-01-01T00:00:00Z", "Valid": false}, "last_connected_at": {"Time": "0001-01-01T00:00:00Z", "Valid": false}, "disconnected_at": {"Time": "0001-01-01T00:00:00Z", "Valid": false}, "resource_id": "fd3fed32-14b9-4b2f-b61f-e40f4392fa2d", "auth_token": "bfcc3cc4-6e3c-4bae-84a3-a917770e4d23", "auth_instance_id": {"String": "", "Valid": false}, "architecture": "amd64", "environment_variables": {"RawMessage": null, "Valid": false}, "operating_system": "linux", "startup_script": {"String": "", "Valid": false}, "instance_metadata": {"RawMessage": null, "Valid": false}, "resource_metadata": {"RawMessage": null, "Valid": false}, "directory": ""}}

@spikecurtis Does this help?

@mafredri
Copy link
Member

Actually, since I can reproduce this quite reliably, I can grab this if nobody's working on it (I'll self assign, let me know if someone is already on it).

@mafredri mafredri self-assigned this May 19, 2022
@spikecurtis
Copy link
Contributor

spikecurtis commented May 19, 2022

This might be a red herring, but why are you setting --address to port 7080, but --access-url to port 3000?

I'm wondering if setting the access URL to port 3000 is causing the workspace coder agent to fail connecting, and this contributes to you being able to repro but I cannot.

I think we need to decide on the desired UX here. Should the CLI wait until coder agents have connected? If so, how long before giving up and throwing an error?

If not, then how to do we communicate to the end user? The reality is that their agent(s) haven't connected yet, but it's probably fine, unless it isn't and then they need to debug.

@mafredri
Copy link
Member

mafredri commented May 19, 2022

Good catch, I think that's bad copy-pasta from some Docker experiments, and it was indeed a red herring since it was being overridden by the Docker template.

I just re-tested, and the behavior is the same. I tried creating 3 workspaces, the two first were left at connecting but the third completed as connected. This is what I saw last time as well.

I think we need to decide on the desired UX here. Should the CLI wait until coder agents have connected? If so, how long before giving up and throwing an error?

I think for a quick improvement we could increase the wait ever so slightly since, as I observed above, it's a tad bit racy at the moment. And after that we just inform the user that we're no longer waiting but their workspace is finishing up. I think that's the best we can do in the create phase without waiting for agent connection. Something like a --follow flag (as in v1) could be an option that lets the user wait for agent connection.

Then again, I don't know how much heavy lifting terraform apply is doing here. Is it waiting until everything has been created successfully, or just scheduling (e.g. with k8s) for creation? If it's the former, it shouldn't take long for the agent to dial home, if it's the latter it could take an hour.

@spikecurtis
Copy link
Contributor

Then again, I don't know how much heavy lifting terraform apply is doing here. Is it waiting until everything has been created successfully, or just scheduling (e.g. with k8s) for creation? If it's the former, it shouldn't take long for the agent to dial home, if it's the latter it could take an hour.

It depends on the terraform template, so we don't have any way to know a priori.

@spikecurtis
Copy link
Contributor

Looks like right now it's not waiting at all; it just queries the resources after the job completes. So it's a race between the agent starting and connecting and the query returning.

@tjcran given that we show the resources we're about to create before the confirm, do we really want to show them again after the job is done? We're not giving the users any new information except for the connection status of agents, and this is the very thing that is racy and confusing. I think we should just drop it at the end of the create command, and users can query it separately if they're interested.

@mafredri
Copy link
Member

I think a small incremental improvement on the UX here would be sufficient, we could track re-thinking the create flow in a new issue.

Regarding the preview and post-resource views, they do give out slightly different information. So not sure we wan't to replace one with the other? (Here I noticed there's a discrepancy between the access output and workspace arch missing in preview, not sure if it's intentional that one says persistent and the other ephemeral though.)

image

image

Anyway, I'll unassign this from me and set the needs decision tag as I think @spikecurtis has some valid points and I lack the context to make a decision about it.

@mafredri mafredri removed their assignment May 20, 2022
@mafredri mafredri added the needs decision Needs a higher-level decision to be unblocked. label May 20, 2022
@f0ssel
Copy link
Contributor Author

f0ssel commented May 20, 2022

I'm in favor of dropping it, @kylecarbs made the original flow so he may have thoughts, but since he's on PTO I don't think we need to wait for his input since he can give input / reimplement correctly later.

@mafredri
Copy link
Member

@f0ssel So we'd be dropping / not showing the resource view after creation? What about the preview, there's a mis-match of information between the two -- which is the source of truth and do we know the persistent/ephemeral status before creation is complete, and do we need to show it?

Do you have any thoughts on this @kylecarbs?

@spikecurtis
Copy link
Contributor

I think what's happening with the resources state being inconsistent is a bug, but it's a different bug than what's being tracked in this issue, so I'll raise a new issue to track: #1937

Let's concentrate on this issue with the "connecting" UX, and I think the best plan is still to just drop the second round of showing the resources on coder create.

@spikecurtis spikecurtis removed the needs decision Needs a higher-level decision to be unblocked. label May 31, 2022
@kylecarbs kylecarbs changed the title Bug: final output on workspace creation shows "connecting" forever - confusing UX Final output on workspace creation shows "connecting" forever - confusing UX Jun 7, 2022
@mafredri mafredri self-assigned this Jun 8, 2022
mafredri added a commit that referenced this issue Jun 8, 2022
This change avoids a confusing UX where the workspace agent shows
"connecting" after create has completed.

Fixes #1036
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api Area: HTTP API docs Area: coder.com/docs
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants