From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox Datacenter Manager development discussion
<pdm-devel@lists.proxmox.com>,
Dominik Csapak <d.csapak@proxmox.com>
Subject: Re: [pdm-devel] [PATCH datacenter-manager] ui: dashboard: add task summary
Date: Wed, 29 Jan 2025 19:18:26 +0100 [thread overview]
Message-ID: <e8fba403-8904-4e4e-bd3b-d30a7659513c@proxmox.com> (raw)
In-Reply-To: <20250123151012.4047891-1-d.csapak@proxmox.com>
Am 23.01.25 um 16:10 schrieb Dominik Csapak:
> similar to what we have in PBS, show some categories of tasks with
> their status counts. When clicking on a count, a filtered view opens
> that only shows those tasks.
>
> This also refactors the option remote task rendering from the running
> tasks list.
>
> It's already prepared that one can provide a given timeframe, currently
> it's hardcoded to 24 hours (like the stastic panels too)
>
Maybe mention the timeframe in parentheses, like e.g.: Task Summary (Last 24h)
I think it might be good to either allow selecting the grouping, i.e. not only
by task-type(-group) like you do now but also per-remote to be able to quickly
determine if a specific remote node/cluster has recent task errors.
As variant of that could also be showing both groupings at the same time, i.e.,
two panels beside each other; would make better use of the space here and require
fewer eyes/head "travel distance" between the label column and the action buttons,
especially on wider browser windows.
Then some other things, which might be also improved on PBS side when applicable
(I did not check the status quo there to closely though):
- The task list window that opens when clicking on one of the action buttons
could do well with providing the task filter bar, maybe with fields that do
not make sense for a specific view hidden though (like the task result type
is preselected anyway, the remote would be preselected for a per-remote
grouping, maybe there are others)
Allowing sorting there might be also nice; we do not show the sort status
at all; albeit they seem sorted descending by their start-time. That would
IMO always make sense, even if we, whyever, do not allow sorting here.
- Show the remote as dedicated column, at least in intra-remote groupings like
the hard coded current one.
- Allowing some sort of go-back flow when opening a specific task log from the
task list window would be nice. Now, one always needs to reopen the list again,
which is a bit of a nuisance.
- tooltips for the error/warning/... icons might be nice, albeit definitively
very fine polishing.
- You do not send an explicit task count limit, so the default of 50 is used
for both the calculation of error/warning/ok from the card and the window.
For the dashboard calculation it might be actually worth to pre-calculate
them in the backend and query them from a cache there, as with thousands of
active remotes (nodes) it might become rather unfeasible of doing all in the
front end.
For the window and the task list we could use paging, as we do not care for
newer tasks that finished since we opened the window it should not be that
hard, one basically just needs to set `until` to the oldest entry (but not
lower, as then one might miss tasks that stopped at the same time) and filter
out any existing. Alternatively one could also add a parameter to the API
to make it handle the UPID as sort of until/since "cursor" (the terminology
that sd-journal uses IIRC), avoiding issues with a lot of tasks that stopped
at exactly the same time.
- With lots of tasks the window grows quite high, this is actually not a
critic, probably more something I need to get accustomed too; but noting
it in case you/others also noticed this. Maybe a _bit_ more headroom above
and below might be good, or some relatively high max-height for those with
displays rotated such that they are taller than wider; but OTOH it's also
good to use the available space.
That's all for now, mostly higher level stuff, albeit I can take a look at
the code too if you want – but IMO the overall (architectural) design is more
important, and with rust one can more safely focus on that, so I did not
bother too much with that (yet) here.
_______________________________________________
pdm-devel mailing list
pdm-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel
prev parent reply other threads:[~2025-01-29 18:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-23 15:10 Dominik Csapak
2025-01-29 18:18 ` Thomas Lamprecht [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e8fba403-8904-4e4e-bd3b-d30a7659513c@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=d.csapak@proxmox.com \
--cc=pdm-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal