This adds a Revert two-step button to the JobVersions component for
not-current versions, which redirects to the overview on success. It
checks the job version before and after reversion to mitigate the edge
case where reverting to an otherwise-identical version has no effect, as
discussed in #10337.
It uses existing facilities for handling other errors and disabling the
button when permissions are lacking.
This adds UI support for receiving the one-time token passed via query parameter, as in #10134
and related PRs, and exchanging it for its corresponding secret ID. When this works, it’s mostly
invisible, with a brief flash of the OTT onscreen.
The authentication failure message now suggests the -authenticate flag.
When OTT exchange fails, it shows a whole-page error.
This includes a known UX shortcoming in that the OTT will not disappear from the URL when an
identifier is specified on the command line, like nomad ui -authenticate jobname. The goal is to
address that shortcoming in a forthcoming pull request.
This closes#8744 and #9826.
It necessitated some customisation options for TwoStepButton. One is inlineText, which puts the confirmation text in the same line as the buttons. Also, there was a single-use configuration option named isInfoAction that I removed in favour of passing a set of class configuration options like this:
@classes={{hash
idleButton="is-warning"
confirmationMessage="inherit-color"
cancelButton="is-danger is-important"
confirmButton="is-warning"}}
Without this, visiting any job detail page on Nomad OSS would crash with
an error like this:
Error: Ember Data Request GET
/v1/recommendations?job=ping%F0%9F%A5%B3&namespace=default returned a
404 Payload (text/xml)
The problem was twofold.
1. The recommendation ability didn’t include anything about checking
whether the feature was present. This adds a request to
/v1/operator/license on application load to determine which features are
present and store them in the system service. The ability now looks for
'Dynamic Application Sizing' in that feature list.
2. Second, I didn’t check permissions at all in the job-fetching or job
detail templates.
This partially addresses #7799.
Task state filesystems are contained within a subdirectory of their
parent allocation, so almost everything that existed for browsing task
state filesystems was applicable to browsing allocations, just without
the task name prepended to the path. I aimed to push this differential
handling into as few contained places as possible.
The tests also have significant overlap, so this includes an extracted
behavior to run the same tests for allocations and task states.
Closes#7197#7199
Note: Test coverage is limited to adapter and serializer unit tests. All
acceptance tests have been stubbed and all features have been manually
tested end-to-end.
This represents Phase 1 of #6993 which is the core workflow of CSI in
the UI. It includes a couple new pages for viewing all external volumes
as well as the allocations associated with each. It also updates
existing volume related views on job and allocation pages to handle both
Host Volumes and CSI Volumes.
This builds on API changes in #6017 and #6021 to conditionally turn off the
“Run Job” button based on the current token’s capabilities, or the capabilities
of the anonymous policy if no token is present.
If you try to visit the job-run route directly, it redirects to the job list.
This sets a default-but-query-configurable Faker seed in development,
via faker-seed. It also changes uses of Math.random to use Faker’s
randomness so auto-generated data remains stable in development.
