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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox