From: Thomas Skinner <thomas@atskinner.net>
To: Daniel Kral <d.kral@proxmox.com>,
Thomas Lamprecht <t.lamprecht@proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH ha-manager 2/2] add api getter/setter for node maintenance mode
Date: Fri, 29 Aug 2025 15:13:48 -0500 [thread overview]
Message-ID: <CALn9RMcFSeGEbf9qdYEbysfd_cDLeHY_P7r4OnyV008Um=gasQ@mail.gmail.com> (raw)
In-Reply-To: <DCD2EZACQ09G.2532NFGSHH9UU@proxmox.com>
On Wed, Aug 27, 2025 at 3:25 AM Daniel Kral <d.kral@proxmox.com> wrote:
>
> On Tue Aug 26, 2025 at 6:00 PM CEST, Thomas Skinner wrote:
> > On Tue, Aug 26, 2025 at 4:38 AM Daniel Kral <d.kral@proxmox.com> wrote:
> >> I think the GET /cluster/ha/nodes/{node}/maintenance API endpoint should
> >> be integrated into the GET /cluster/ha/nodes/{node} instead as putting a
> >> node in/out of maintenance mode is only an action, but the state could
> >> be more than just the node being in maintenance mode.
> >>
> >> On second thought, is this API endpoint even used at all in the patch
> >> series?
> >
> > The API isn't specifically used here, but we have found it useful in
> > our local branch to have it so that we can query the transition of the
> > state of a host directly. I figured someone else might find it useful
> > as well, so I left it in here. If it should be removed, I can remove
> > it in the v2 series.
>
> I see, the only thing I'm still worried about is that in the current
> state the API endpoint might expose more internal structure than
> necessary and should at least be documented in the API schema and/or
> abstracted away.
>
> @Thomas do you have an opinion on this?
>
> >
> >> > +
> >> > +__PACKAGE__->register_method ({
> >> > + name => 'maintenance_set',
> >> > + protected => 1,
> >> > + path => 'maintenance',
> >> > + method => 'POST',
> >> > + description => "Change the node-maintenance request state.",
> >> > + permissions => {
> >> > + check => ['perm', '/', [ 'Sys.Console' ]],
> >> > + },
> >> > + parameters => {
> >> > + additionalProperties => 0,
> >> > + properties => {
> >> > + node => get_standard_option('pve-node'),
> >> > + disable => {
> >> > + description => "Requests disabling or enabling maintenance-mode.",
> >> > + type => 'boolean',
> >>
> >> Hm, I see that that part is from the CLI handler, but there `disable` is
> >> only used for two different subcommands `enable` and `disable`, so
> >> wouldn't it be neater to have two API endpoints for that instead? Like
> >> for example the API endpoints for VM/container start/stop/..., e.g.
> >>
> >> - POST enable_maintenance
> >> - POST disable_maintenance
> >
> > For this, I was mirroring the existing underlying API calls as listed
> > below, but I agree that enable/disable would be more clear. I'll put
> > that in the v2 series.
>
> Hm, I've only looked at the PVE API now, but one similar feature is the
> PBS's maintenance mode for datastores [0], which are set by a single,
> enum property 'maintenance-mode' in a PUT request.
>
> Maybe we could add the same PUT method to @Thomas' proposed
> /nodes/{node}/maintenance API endpoint, because AFAICT for non-HA use
> cases we'd need some way to enable and disable maintenance mode there
> too. That's also cleaner than introducing two very similar endpoints
> with quite long, weirdly-cased names.
>
> [0] https://pbs.proxmox.com/docs/api-viewer/index.html#/config/datastore/{name}
>
If the API for maintenance mode is under the /nodes/{node}/maintenance
as @Thomas proposed, does it still make sense to put the code for the
API into the ha-manager package instead of the manager package? I like
the idea of the enum under this endpoint e.g. something like PUT
/nodes/{node}/maintenance --maintenance-mode enable|disable. To be
more specific to HA, could use something like --lrm-maintenance
enable|disable that way the maintenance-mode enum could stay free if
it was wanted for the more generic maintenance mode and it would
convey to the user that it was specific to HA only.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2025-08-29 20:14 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-25 4:11 [pve-devel] [PATCH SERIES docs/ha-manager/manager] close #6144: add ui button + api " Thomas Skinner
2025-08-25 4:11 ` [pve-devel] [PATCH ha-manager 1/2] add additional api field for lrm_mode in status check Thomas Skinner
2025-08-25 4:11 ` [pve-devel] [PATCH manager 1/2] add api path map for node HA endpoints Thomas Skinner
2025-08-26 9:38 ` Daniel Kral
2025-08-26 10:26 ` Thomas Lamprecht
2025-08-26 11:34 ` Daniel Kral
2025-08-25 4:11 ` [pve-devel] [PATCH docs 1/1] add docs for maintenance mode buttons in UI Thomas Skinner
2025-08-26 9:44 ` Daniel Kral
2025-08-26 16:05 ` Thomas Skinner
2025-08-27 7:50 ` Daniel Kral
2025-08-25 4:11 ` [pve-devel] [PATCH ha-manager 2/2] add api getter/setter for node maintenance mode Thomas Skinner
2025-08-26 9:38 ` Daniel Kral
2025-08-26 16:00 ` Thomas Skinner
2025-08-27 7:31 ` Thomas Lamprecht
2025-08-27 8:25 ` Daniel Kral
2025-08-27 9:20 ` Thomas Lamprecht
2025-08-29 20:13 ` Thomas Skinner [this message]
2025-09-01 8:52 ` Daniel Kral
2025-08-29 20:17 ` Thomas Skinner
2025-08-25 4:11 ` [pve-devel] [PATCH manager 2/2] add UI for node maintenance enable/disable Thomas Skinner
2025-08-26 10:00 ` Daniel Kral
2025-08-26 17:34 ` Thomas Skinner
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='CALn9RMcFSeGEbf9qdYEbysfd_cDLeHY_P7r4OnyV008Um=gasQ@mail.gmail.com' \
--to=thomas@atskinner.net \
--cc=d.kral@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=t.lamprecht@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.