* Unknown status for allocations accounted for
* Canary string removed
* Test cleanup
* Generate unknown in mirage
* aacidentally oovervoowled
* Update ui/app/components/allocation-status-bar.js
Co-authored-by: Derek Strickland <1111455+DerekStrickland@users.noreply.github.com>
* Disconnected state on job status in client
* Renaming Disconnected to Unknown in the job-status-in-client
* Unknown accounted for on job rows filtering and testsfix
* Adding lostAllocs as a computed dependency
* Unknown client status within acceptance test
* Swatches updated and PR comments addressed
* Unknown and disconnected added to test fixtures
Co-authored-by: Derek Strickland <1111455+DerekStrickland@users.noreply.github.com>
All breadcrumbs do not need a title property because some views
drill down by using a tab-based UI (e.g. CSI volumes and the Job Overview)
The goal is to help us identify breadcrumbs that are non-descriptive (i.e.
breadcrumbs that display as an ID).
This doesn’t include Ember Data, as we are still back on 3.12.
Most changes are deprecation updates, linting fixes, and dependencies. It can
be read commit-by-commit, though many of them are mechanical and skimmable.
For the new linting exclusions, I’ve added them to the Tech Debt list.
The decrease in test count is because linting is no longer included in ember test.
There’s a new deprecation warning in the logs that can be fixed by updating Ember
Power Select but when I tried that it caused it to render incorrectly, so I decided to
ignore it for now and address it separately.
Manual interventions:
• decorators on the same line for service and controller
injections and most computed property macros
• preserving import order when possible, both per-line
and intra-line
• moving new imports to the bottom
• removal of classic decorator for trivial cases
• conversion of init to constructor when appropriate
This is extracted from #8094, where I have run into some snags. Since
these ESLint fixes aren’t actually connected to the Ember 3.16 update
but involve changes to many files, we might as well address them
separately. Where possible I fixed the problems but in cases where
a fix seemed too involved, I added per-line or -file exceptions.
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.
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.
