[ui] Actions service and flyout

[philrenaud]

A re-think to how we've handled Nomad Actions in the UI. Specifically, this means to address:

• Session-permanence of Actions. Formerly, the output of an Action existed in the context of a small "toast" notification in the bottom-right of the UI. Many of these could stack, making them cumbersome, and when closed (say, to save space on one's screen), the socket was closed as a result. Now, we have a dedicated flyout for holding a queue of actions, which can be closed without affecting the running action.
• A global queue of actions. Actions previously existed within the context of a job and handling of their sockets and messages was done in the ephemeral adapter layer. In this PR, we establish the Actions Service, which can be injected throughout different pages in the app (to indicate how many background actions are running from the application homepage, for example)
• Multi-alloc actions / peer handling. A feature of Nomad actions is that they can be run on individual allocations, or repeated efficiently across many allocations. The updated UI establishes "peer" allocations where an action is running, to greatly consolidate the footprint of a running action.

Resolves #19066

[github-actions]

Ember Test Audit comparison

	main	532f7ae	change
passes	1538	1539	+1
failures	0	0	0
flaky	0	0	0
duration	10m 42s 460ms	10m 45s 538ms	+03s 078ms

[philrenaud]

This file previously did much more than an Ember adapter ought to; it has since been moved to a dedicated Action service.

[philrenaud]

A componentized dropdown/select box, which we use on the Job page, the Task page, and within the Actions flyout (within the context of a job or a task)

[philrenaud]

A representation of a running action instance, or group of peered instances.

Here's 2 action-cards:

[pkazmierczak]

LGTM! Great work, Phil!

I found the code surprisingly straightforward to follow (coming from a non-JS background) and very well-structured and clearly written.

I did a lot of smoke-testing and the feature behaves as expected, with some corner cases that I described in the comments.

[pkazmierczak]

There's something 🐟-y going on here. Whenever I stop actions, I get websocket errors from Nomad API.

    2023-11-23T15:17:59.002+0100 [ERROR] http: request failed: method=GET path="/v1/job/actions-demo/action?namespace=default&action=echo%20time&allocID=d2604ab1-97d2-2e0a-ee02-448aad287525&task=task&group=group&tty=true&ws_handshake=true" error="websocket: close 1005 (no status)" code=500

[philrenaud]

This is fixed by #19172 (thank you, @pkazmierczak!)

[pkazmierczak]

This is very well structured and easy to read code, I like it.

I found an issue with permissions that I'm a bit confused with. If I give myself a read policy with no write permissions, the behavior is as expected: no actions-related widgets or buttons appear anywhere in the UI. So far so good. But if I give myself a minimal ACL that should allow me to use actions:

namespace "default" {
  policy       = "read"
  capabilities = ["alloc-exec", "alloc-lifecycle"]
}

I then do get actions-related buttons and widgets, but whenever I try to run an action, I get a 500, and no output.

Logs say it's a permissions issue:

    2023-11-23T15:48:38.229+0100 [ERROR] http: request failed: method=GET path="/v1/job/actions-demo/action?namespace=default&action=weather&allocID=5a2ba29f-ae21-cab1-df29-388a8bd081b7&task=task&group=group&tty=true&ws_handshake=true" error="Permission denied" code=500

But the code is wrong then, shouldn't be a 500. Also the UI doesn't give useful feedback on this:

Wouldn't it be better if it said that it's a permissions issue?

Or am I perhaps setting the ACL wrong somehow?

[philrenaud]

Note: in testing this out, noticed that raw_exec jobs required both alloc-exec AND alloc-node-exec capabilities. Updating the docs to reflect.

[philrenaud]

Hi @pkazmierczak , thanks for the review — opened up an issue re: error frames/response headers not surfacing for websockets @ #19164

IMO we should handle that separate of this PR, but it should still be handled.

[pkazmierczak]

IMO we should handle that separate of this PR

agreed.

[github-actions]

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.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.