[ui] Actions implementation in the web UI #18793
Conversation
Ember Test Audit comparison
|
philrenaud
force-pushed
the
18735-socket-endpoint
branch
from
fb1f31a to
0a308a1
Compare
philrenaud
force-pushed
the
18782-implementation-on-job-index
branch
from
ef434de to
b89d27a
Compare
philrenaud
force-pushed
the
18782-implementation-on-job-index
branch
from
477cfb4 to
14bec47
Compare
philrenaud
changed the title
philrenaud
force-pushed
the
18782-implementation-on-job-index
branch
2 times, most recently
from
b14f50e to
b23a7f2
Compare
philrenaud
force-pushed
the
18782-implementation-on-job-index
branch
from
b23a7f2 to
10a21d1
Compare
philrenaud
force-pushed
the
18782-implementation-on-job-index
branch
from
eb50790 to
c34b2e1
Compare
philrenaud
force-pushed
the
18782-implementation-on-job-index
branch
from
c34b2e1 to
44bfe6b
Compare
philrenaud
force-pushed
the
18782-implementation-on-job-index
branch
from
f182b8d to
aec93d4
Compare
philrenaud
force-pushed
the
18782-implementation-on-job-index
branch
from
aec93d4 to
c86c7a0
Compare
There was a problem hiding this comment.
Super awesome work!
I think the headline for me (granted I haven't been in this code in a minute) is that there is a lot of exposure to websocket and xterm details in the action adapter.
There's a good chance that code never has to be looked at again, so I don't want to go so far as to say it should be refactored, but since we already have some of those utils for full-blown exec, maybe there is an opportunity to organize some of the common code.
ui/app/adapters/job.js
Outdated
| const protocol = window.location.protocol === 'https:' ? 'wss:' : 'ws:'; | ||
| const region = this.system.activeRegion; | ||
| const applicationAdapter = getOwner(this).lookup('adapter:application'); | ||
| const prefix = `${ | ||
| applicationAdapter.host || window.location.host | ||
| }/${applicationAdapter.urlPrefix()}`; | ||
|
|
||
| const wsUrl = | ||
| `${protocol}//${prefix}/job/${encodeURIComponent(job.get('id'))}/action` + | ||
| `?namespace=${job.get('namespace.id')}&action=${ | ||
| action.name | ||
| }&allocID=${allocID}&task=${action.task.name}&group=${ | ||
| action.task.taskGroup.name | ||
| }&tty=true&ws_handshake=true` + | ||
| (region ? `®ion=${region}` : ''); | ||
|
|
||
| // const socket = new WebSocket(wsUrl); | ||
| let socket; |
There was a problem hiding this comment.
Does it make sense to eventually try to use the sockets service here?
There was a problem hiding this comment.
Ended up starting/stopping on this a couple times today; I think it's a good idea and will be marking it a TODO but I'm worried about drift from the exec implementation enough that I want to give it more consideration.
| JSON.stringify({ | ||
| tty_size: { width: 250, height: 100 }, // Magic numbers, but they pass the eye test. | ||
| }) |
There was a problem hiding this comment.
I believe this is what we use the xterm-addon-fit for over in ExecTerminal.
| } | ||
|
|
||
| if (job.groupAllocCount) { | ||
| groupProps.count = job.groupAllocCount; |
There was a problem hiding this comment.
I suppose it was only a matter of time before this needed to be disambiguated.
philrenaud
force-pushed
the
18782-implementation-on-job-index
branch
from
c86c7a0 to
7bf345a
Compare
philrenaud
force-pushed
the
18782-implementation-on-job-index
branch
from
56f1cfa to
e828a3c
Compare
philrenaud
force-pushed
the
18782-implementation-on-job-index
branch
from
e828a3c to
036d61e
Compare
|
I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions. |
The Web UI implementation of Nomad Actions
This adds Actions dropdowns to job pages and task rows in tables and jobs where applicable, then runs a websocket query to execute them against a new job/:id/action endpoint.
PR review note: there is quite a bit of noise here from a
groupTaskCounttogroupAllocCountfor in many mirage mocked jobs. This name better reflects what is actually being done in the job factory, as I've added a lever to help separate out task and alloc counts when creating one (this became relevant in order to mock a job with multiple groups with differing numbers of tasks and allocs)Another note on design: the "streaming messages in a code block in a notification" is probably not the end state of the design for this feature, but since it is still in flux, I've opted to move this PR forward and address design changes in the near future.