This closes#7454. It makes use of the existing watchable tools to
allow the exec popup sidebar to be live-updating. It also adds
alphabetic sorting of task groups and tasks.
Most tests bypass setting the token via the UI, instead choosing
to set it in localStorage directly, because the acceptance tests
for the token UI are sufficient to exercise that part of the UI,
so this speeds up the test a bit.
This is a minimal implementation that closes#7463. It doesn’t include
true support for moving around within the command to edit using arrow
keys because it gets too complex when managing wrapping at the edge of
the terminal. Instead, arrow keys are ignored. It also ignores ^A and
^E, which are cursor manipulations that pose similar problems to arrow
keys. It does support ^U, which deletes the entire command.
It also allows a command to be pasted, which was previously unsupported.
This is accomplished by migrating from Xterm.js’s onKey handler to
onData, which is recommended here:
https://github.com/xtermjs/xterm.js/issues/2673#issuecomment-574897733
onData is a higher-level handler that issues events with the final
interpreted data instead of the individual key events. That means the
processing in this PR has changed from inspecting DOM key events to
inspecting their ASCII equivalents, which I’ve extracted into a utility
dictionary for use in tests and implementation.
One consequence of ignoring most control characters is that if you paste
a string that includes a control character, that character will be
stripped. It’s somewhat strange for compound sequences like arrow keys;
if you run copy('/bin/b' + '\x1b[D' + 'ash') in a Javascript console and
paste what’s on the clipboard, you get "/bin/b[Dash". That’s because
the left arrow key, as in that centre portion of the string,
is represented by the escape character and a coded sequence. Stripping
the control character leaves the coded sequence as part of the paste.
That seems like an acceptable compromise vs either ignoring any pasted
string with control characters (confusing UX) or trying to interpret and
strip all such compound control sequences (difficult to be exhaustive).
When a node has no host volumes, the API response will
have a null value for the HostVolumes attribute, which
in turn becomes a null value instead of an empty array
in the store. This protects against that, ensuring host
volumes is always an array.
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 connects Xterm.js to a Nomad exec websocket so people
can interact on clients via live sessions. There are buttons on
job, allocation, task group, and task detail pages that open a
popup that lets them edit their shell command and start a
session.
More is to come, as recorded in issues.
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.
I unintentionally introduced a flapping test in #6817. The
draining status of the node will be randomly chosen and
that flag takes precedence over eligibility. This forces
the draining flag to be false rather than random so the
test should no longer flap.
See here for an example failure:
https://circleci.com/gh/hashicorp/nomad/26368
There are two changes here, and some caveats/commentary:
1. The “State“ table column was actually sorting only by status. The state was not an actual property, just something calculated in each client row, as a product of status, isEligible, and isDraining. This PR adds isDraining as a component of compositeState so it can be used for sorting.
2. The Sortable mixin declares dependent keys that cause the sort to be live-updating, but only if the members of the array change, such as if a new client is added, but not if any of the sortable properties change. This PR adds a SortableFactory function that generates a mixin whose listSorted computed property includes dependent keys for the sortable properties, so the table will live-update if any of the sortable properties change, not just the array members. There’s a warning if you use SortableFactory without dependent keys and via the original Sortable interface, so we can eventually migrate away from it.
As the angle bracket invocation RFC says:
> There is no dedicated syntax for passing an "else" block
> directly. If needed, that can be passed using the named
> blocks syntax.
https://github.com/emberjs/rfcs/blob/master/text/0311-angle-bracket-invocation.md#block
Unfortunately, using a contextual component doesn’t help as
the yield inside that component will still result in content
rendering that would show when the source isn’t empty. So
we decided to change the interface so you have to check
whether the source is empty before using it, which aligns with
how list-table works.
This is mostly deprecation fixes and blueprint changes. There
are some dependency updates too; the changes to Ember
Basic Dropdown necessitated changing it to angle bracket
component invocation. The conversion of the rest of the
templates will happen separately.
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.
The recurring problem here was that sometimes the factories would
generate more than one task, and it was random whether the task
with the proxy task would be the first in the list. This ensures
that the proxy task is always first so the tests can run again.
This fixes a race condition in the pseudo-relationship between a
TaskState and a Task that was causing the Consul Connect proxy tag
to sometimes show on the wrong task. There’s no direct Ember Data-style
relationship between a TaskState and its Task; instead, it’s determined
by searching for a Task with the matching name. The related Task was
sometimes stored before everything was ready and not recalculated when
the name became known. This ensures the relationship is accurate if the
TaskState’s name property changes.
I put this property in the wrong place.
I’ve found how to fix the mock API in the tests but
they’re failing to pass with headless Chrome only,
so they’re skipped for now.
When sorting by size, directories are sorted by name, as size
isn’t displayed.
This includes a change to the positioning of sort arrows for all tables,
moving them closer to the text, because in some cases, the arrows
for right-aligned columns were ambiguously positioned.
This uses ember-page-title to add dynamic page titles throughout the
route hierarchy. When there’s more than one region, the current
current region is added before the final entry of “- Nomad”.
The draining, eligibility, and status fields now all show under a combined
state column. Draining takes precedence, then (in)eligibility; if neither of
those is true, the status displays.
Since one allocation is preempted, the alloc factory creates a new alloc
that wasn't guaranteed to be running. When it is the first alloc row in
the table, then the alloc row detail test fails because non-running
allocs don't have metrics. The fix was to manually update all the alloc
clientStatuses.
This exports a function that returns the pertinent function when given a
container. This way it works in registerHelper and in integration tests
beforeEach hooks
