Arvados

21297-container-status @ 945b25b098eaa08722698a0e33c10e2e68770a6c

developer-run-tests: #4401

• All agreed upon points are implemented / addressed.
  • now displays scheduling information on the process page when available
• Anything not implemented (discovered or discussed during work) has a follow-up story.
  • Currently doesn't do any polling to keep scheduling status up to date, need to decide if that should be part of this story or not.
• Code is tested and passing, both automated and manual, what manual testing was done is described
  • passes existing tests. I did not add new tests. Tested manually by running jobs on tordo and checking that the new scheduling status text was displayed when the container was queued.
• Documentation has been updated.
  • n/a
• Behaves appropriately at the intended scale (describe intended scale).
  • Adds a query to the container_status API when loading a container
• Considered backwards and forwards compatibility issues between client and server.
  • Expects that the container_status API (coming in 3.0) to be available. Sets showErrors to false so if used with an old API server, it will get an error, but the error will not be displayed to the user.
• Follows our coding standards and GUI style guidelines.
  • yes

Ideally this should include polling the container status API to keep the display up to date. I'm not sure how best to go about doing that.

Lisa Knox wrote in #note-28:

The first thing I notice is that there is no status display when first displaying a process, and then a status appears when clicking "run." Ideally there would be a placeholder there, something to let the user know that this is where. I know this is done to be compatible with the <3.0 API, but it looks bad when using the new API.

I added a placeholder for the "Draft" state (which is the state it is in when you use "copy and re-run process")

Granted, I'm not as fluent with this workflow as I could be, but at a glance this just looks confusing, especially the "Scheduling: not scheduling: " bit.

These messages come from arvados-dispatch-cloud, so it is out of scope for the Workbench feature, but I agree that the messages could use some work to better explain what is going on. I'll make a follow up ticket.

As far as testing, we will get the most value out of tests after polling is implemented. I would imagine that the same useAsyncInterval technique used in the subprocess progress bar ( https://dev.arvados.org/projects/arvados/repository/arvados/revisions/main/entry/services/workbench2/src/common/use-async-interval.ts ) would work for polling, with very little modification.

Thank you for pointing me in the right direction, useAsyncInterval was pretty easy to implement.

Still need to figure out testing. I'm kind of holding off on writing tests until the Material UI branch merges to minimize conflicts.

21297-container-status @ 3eed169f656321b0808a40fd8b095774432b6c6b

developer-run-tests: #4405

Great, this all LGTM

merged main

21297-container-status @ 40e9757532f7f52524a2c626bf1425b000cd7e56

developer-run-tests: #4436