Now all data loading happens in the TopoViz component as well as
computation of resource proportions.
Allocation selection state is also managed centrally uses a dedicated
structure indexed by group key (job id and task group name). This way
allocations don't need to be scanned at the node level, which is O(n) at
the best (assuming no ember overhead on recomputes).
- Plot all datacenters
- For each datacenter, plot all nodes
- For each node, plot all allocations by memory and cpu
- For empty nodes, highlight the emptiness
- When hovering over allocations, give them visual focus
The job factory will now accept an array of resourceSpecs that is a shorthand
notation for memory, cpu, disk, and iops requirements.
These specs get passed down to task groups. The task group factory will
split the resource requirements near evenly (there is variance
threshold) across all expected tasks.
Allocations then construct task-resource objects based on the resources
from the matching task.
My suggestion is that this table isn’t sufficiently useful to
keep around with the combinatoric explosion of other lifecycle
phases. The logic was that someone might wonder “why isn’t my
main task starting?” and this table would show that the prestart
tasks hadn’t yet completed. One might wonder the same about
any task that has prerequisites, so should a poststart task have
a table that shows main tasks? And so on.
Since the route hierarchy guarantees that one has already passed
through a template that shows the lifecycle chart before one
can reach the template where this table is displayed, I believe
this table is redundant. It also conveys information in a more
abstract way than the chart, which is dense and more easily
understood, to me.
This continues #8455 by adding accessibility audits to component integration
tests and fixing associated errors. It adds audits to existing tests rather than
adding separate ones to facilitate auditing the various permutations a
component’s rendering can go through.
It also adds linting to ensure audits happen in component tests. This
necessitated consolidating test files that were scattered.
This extracts some common API-idiosyncracy-handling patterns from model serialisers into properties that are processed by the application serialiser:
* arrayNullOverrides converts a null property value to an empty array
* mapToArray converts a map to an array of maps, using the original map keys as Name properties on the array maps
* separateNanos splits nanosecond-containing timestamps into millisecond timestamps and separate nanosecond properties
Displays all scale events in the form of an annotated line chart. When
annotations are clicked, the timestamp, message, and meta propeties for
the event are displayed below the chart.
This makes use of the PR I recently had merged to eslint-plugin-ember-a11y-testing
to add linting that ensures an accessibility audit is called at least once per acceptance
test file. When I have added linting for component tests, it can apply there too.
I added exclusions for the filesystem browser tests, which are covered by behaviors/fs
and for the search test which will involve significant overrides to Ember Power Select
default templates.
This introduces ember-a11y-testing to acceptance tests via a helper
wrapper that allows us to globally ignore rules that we can address
separately. It also adds fixes for the aXe rules that were failing.
The spacing has been broken for job types that use this yield
(parameterised and periodic) since I added the exec button
to this template. This could be further refined to allow a more
logical grouping of elements where buttons and tags are
separate.
Thanks to @notnoop for this UX improvement suggestion.
The allocation’s task group is always known, so it
might as well be preselected in the sidebar when the
exec window opens. Also, if the task group only has
one task, might as well preselect it too.
This closes#8422, another bug facilitated by the difficulty
of automated testing when opening another window. Thanks to
@notnoop for narrowing this down.
This updates the Ember edition setting to Octane, which I removed from #8319
because it required the template-only Glimmer components setting to be turned
on, which this does. These changes to templates accommodate that setting.
This includes fixes for newer template lint rules that came along with
updating that dependency, which was necessary to be able to use
the no-curly-component-invocation rule. It also updates some curly
invocations that I missed in #8075.
This updates to Ember 3.16 but leaves Ember Data at 3.12 so we don’t need
to use the model fragments beta. It can be reviewed on a commit-by-commit
basis: blueprint updates, fixes for test failures, and the removal of
now-deprecated partials.
It’s not a true update to Octane as that would involve turning on template-only
components by default, which breaks various things. We can accomplish that
separately and then add the edition setting to package.json.
Thanks to @cibernox’s isActive clarification in
cibernox/ember-power-select#1374, this replaces the use
of a hacked Power Select API with a deliberate blurring
of the trigger element, which is equivalent to setting
the element to inactive.
The CSS I added in #8249 to make the search be properly
centred also made the logo unclickable as it was hidden
behind the centred element! This makes the logo stay
above the search container.
- Click label to focus input
- Focusing input selects value
- Entering an invalid value reverts selection
- Entering a fractional number floors the value
This updates the look of the search control, adds a hint about the slash
shortcut, adds highlighting of fuzzy search results, and addresses a few
edge case UX failures. It moves to using a fork of Ember Power Select
to handle an edge case where pressing escape would put the control
in an undesirable active-but-not-open state.
Sometimes a job would be created with a running deployment which made
the increment button disabled.
While I was finding the root cause, I also changed the waitUntil pattern
to match the StepperInput technique which is more resilient to code
changes.
Adding keys tells Ember to rerender matching entries instead of
destroying and recreating.
Without this key, every time the allocation collection changes, every
allocation row gets destroyed and recreated.
This happens a lot, since each allocation needs to be reloaded which
dirties the collection.
Since allocation rows fetch stats on init, each of these many many
renders results in a stats request.
By using key and rerendering matching records, this all goes away. Since
the rows aren't being destroyed and recreated, the init stats request
isn't being made overnumerously.
This introduces a DataCaches service so recently-updated collections don’t need
to be requeried within a minute, or based on the current route. It only searches
jobs and nodes. There are known bugs that will be addressed in upcoming PRs.
Michael Lange