From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Gabriel Goller <g.goller@proxmox.com>,
Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup v3] close #4723: updated gc view in the ui
Date: Fri, 22 Sep 2023 13:49:32 +0200 [thread overview]
Message-ID: <7d77cb78-4601-4da2-aa15-4b9f61aa401f@proxmox.com> (raw)
In-Reply-To: <456bfe52-2a87-e61c-3d2c-ef9b9fccb468@proxmox.com>
Am 22/09/2023 um 12:45 schrieb Gabriel Goller:
> Am 22/09/2023 um 11:36 schrieb Thomas Lamprecht:
>> In general, it can be fine to do API and UI in one patch if they are
>> quite coupled, and it's a relatively small and targeted feature. But, if
>> there's existing UI code it still can be nicer to split this so one can
>> differ easier between file-movement changes and actual code changes
>> (git's color-moved isn't IME that helpful)
> So I should submit one patch with the new api endpoint, another one
> with moving the gc view ouf of the file (which I will have to create because
> the PrunceAndGCView makes one api request for both tables and uses the
> same store) and another one for the new ui?
Hmm, forgot that this is using a shared store currently. So yeah, that
make such a split rather busy work..
I'd then maybe just split UI and API into two separate patches, but not
so hard feelings here.
>> [...]
>>
>>>> + // calculate next event
>>>> + if let Some(schedule) = &store_config.gc_schedule {
>>>> + if let (Ok(event), Some(last_run)) = (
>>>> + schedule.parse::<CalendarEvent>(),
>>>> + computed_schedule.last_run_endtime,
>>>> + ) {
>>>> + if let Ok(next_event) = event.compute_next_event(last_run) {
>>>> + computed_schedule.next_run = next_event;
>>>> + }
>>>> + }
>>>> + }
>>>
>>> If GC never ran but is scheduled, it would also be nice to show the next
>>> scheduled run.
>>> This might be usefull if people had not GC configured, then create a job
>>> to further indicate that the job is scheduled correctly.
>>>
>>>
>> I did not check it out closely, but how is the situation handled if it's
>> currently running, returning that under "last_run_upid" would be
>> probably confusing, but without >UPID one cannot allow one to open the
>> log easily, or do we want to have this strictly for last- and next-run?
> Showing the log while the gc is running was never possible (except when you
> manually start it from the ui, then it opens automatically) but we could implement
> a "Show Log" button as we have the `upid`...
>
Yeah, I know that it wasn't possible, but seeing the last state wasn't
either until your patch ;-)
I'm just thinking about what a user might expect to see if there's a
currently running GC operation.
> When the gc job is currently running, we display a spinner on the status row. To find
> out if the gc job is currently running, we simply check if the `upid` exists and the
> `last_run_endtime` does not.
In the UI of the Proxmox VE replication framework there's also a spinner
if there's currently running a log, but if I press the available "Log"
button there, I then get the task-viewer of the current log, which
has its merits. And, FWIW, GC often runs much longer than a
delta-replication.
FWIW, you could always set the UPID and use the availability of the
"last-run-endtime" property as information for if the task is finished
or still running.
next prev parent reply other threads:[~2023-09-22 11:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-20 17:02 Gabriel Goller
2023-09-22 9:36 ` Thomas Lamprecht
2023-09-22 10:45 ` Gabriel Goller
2023-09-22 11:49 ` Thomas Lamprecht [this message]
2023-09-27 13:05 ` Gabriel Goller
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=7d77cb78-4601-4da2-aa15-4b9f61aa401f@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=g.goller@proxmox.com \
--cc=pbs-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