From: Christian Ebner <c.ebner@proxmox.com>
To: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>,
Max Carrara <m.carrara@proxmox.com>
Subject: Re: [pbs-devel] RFC: Scheduler for PBS
Date: Fri, 9 Aug 2024 13:22:31 +0200 (CEST) [thread overview]
Message-ID: <1045470937.13120.1723202551905@webmail.proxmox.com> (raw)
In-Reply-To: <D3B9YIIHKRP2.2EX6MKWE3C0NP@proxmox.com>
> On 09.08.2024 11:31 CEST Max Carrara <m.carrara@proxmox.com> wrote:
> Architectural Overview
> ----------------------
>
> The scheduler internally contains the type of job queue that is being
> used, which in our case is a simple FIFO queue. We also used HTTP
> long-polling [3] to schedule backup jobs, responding to the client only
> when the backup job is started.
>
> While long-polling appears to work fine for our current intents and
> purposes, we still want to test if any alternatives (e.g.
> "short-polling", as in normal polling) are more robust.
>
> The main way to communicate with the scheduler is via its event loop.
> This is a plain tokio task with an inner `loop` that matches on an enum
> representing the different events / messages the scheduler may handle.
> Such an event would be e.g. `NewBackupRequest` or `ConfigUpdate`.
>
> The event loop receives events via an mpsc channel and may respond to
> them individually via oneshot channels which are set up when certain
> events are created. The benefit of tokio's channels is that they can
> also work in blocking contexts, so it is possible to completely isolate
> the scheduler in a separate thread if needed, for example.
>
> Because users should also be able to dynamically configure the
> scheduler, configuration changes are handled via the `ConfigUpdate`
> event. That way even the type of the queue can be changed on the fly,
> which one prototype is able to do.
>
> Furthermore, our prototypes currently run inside `proxmox-backup-proxy`
> and are reasonably decoupled from the rest of PBS, due to the scheduler
> being event-based.
Thanks for the write-up, this does sound interesting!
Do you plan to also include the notification system, e.g. by sending out notification events based on events/messages handled by the scheduler? Or will that solely be handled by the worker tasks?
What about periodic tasks that should be run at a given time, e.g. for server side alerts/monitoring tasks [0]? From you description I suppose these would simply be a different job type, and therefore be queued/executed based on their priority?
Can you already share some code (maybe of one of the prototypes), so one can have a closer look and do some initial testing or is it still to experimental for that?
Cheers,
Chris
[0] https://bugzilla.proxmox.com/show_bug.cgi?id=5108
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
next prev parent reply other threads:[~2024-08-09 11:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-09 9:31 Max Carrara
2024-08-09 11:22 ` Christian Ebner [this message]
2024-08-09 12:33 ` Max Carrara
2024-08-09 12:52 ` Dominik Csapak
2024-08-09 14:20 ` Max Carrara
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=1045470937.13120.1723202551905@webmail.proxmox.com \
--to=c.ebner@proxmox.com \
--cc=m.carrara@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.