From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Aaron Lauterer <a.lauterer@proxmox.com>
Subject: Re: [pve-devel] [PATCH manager 4/6] api: mon: mds: osd: add safety check endpoints
Date: Tue, 22 Feb 2022 09:44:50 +0100 [thread overview]
Message-ID: <d3fb75b3-7b08-51a1-1c53-35ab743efaa9@proxmox.com> (raw)
In-Reply-To: <20220218113827.1415641-5-a.lauterer@proxmox.com>
On 18.02.22 12:38, Aaron Lauterer wrote:
> for mon, mds and osd: ok-to-stop
> mon: ok-to-rm
> osd: safe-to-destroy
>
> Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
> ---
>
> I added the OSD safe-to-destroy endpoint even though I have no immediate
> use for it as of now. But plan to include it in the OSD panel once I
> have an idea how to do so in a sensible manner.
>
> The main problem with safe-to-destroy is, that it only works if the OSD
> is still running and by the time we enable the destroy button, the OSD
> needs to be stopped.
above isn't really meta info for review but rather important for the commit
message itself.
In general I see lots of repetition, and in this case I'd rather have a single
enpoint that accepts one (or maybe better a list of) service-type(s), and an
action (stop/destroy) let's encode in the name (or at least description) that
it's a heuristical check, besides things that we possible miss to observe we
could never make it 100% safe as we cannot lock the whole ceph cluster between
checking and doing an operation, so this will always be a TOCTOU race that
expects the admins to have some change management so that they do not interfere
with each others maintenance work.
So either `/nodes/<nodename>/ceph/cmd-safety-heuristic` or drop the heuristic
from the path and just refer to that detail in the description (which shows up
in the api viewer, so should be good enough) `/nodes/<nodename>/ceph/cmd-safety`
params could be: node, type, id and command
>
> PVE/API2/Ceph/MDS.pm | 50 ++++++++++++++++++++++
> PVE/API2/Ceph/MON.pm | 100 +++++++++++++++++++++++++++++++++++++++++++
> PVE/API2/Ceph/OSD.pm | 100 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 250 insertions(+)
>
> diff --git a/PVE/API2/Ceph/MDS.pm b/PVE/API2/Ceph/MDS.pm
> index 1cb0b74f..2ed3cf5a 100644
> --- a/PVE/API2/Ceph/MDS.pm
> +++ b/PVE/API2/Ceph/MDS.pm
> @@ -230,4 +230,54 @@ __PACKAGE__->register_method ({
> }
> });
>
> +__PACKAGE__->register_method ({
> + name => 'oktostop',
FYI: the name is usable to call this directly via code API2::Ceph::MDS->oktostop(),
so it would be good to use the perl method naming convention.
> + path => '{name}/ok-to-stop',
> + method => 'GET',
> + description => "Check if it is ok to stop the MON",
"heuristic check if..."
> + proxyto => 'node',
> + protected => 1,
> + permissions => {
> + check => ['perm', '/', [ 'Sys.Modify' ]],
> + },
hmm, why Sys.Modify, I mean this doesn't do anything so Sys.Audit could be argued
too, or did you have something other in mind here (e.g., consistency with some other,
similarly categorized api endpoint)?
> + parameters => {
> + additionalProperties => 0,
> + properties => {
> + node => get_standard_option('pve-node'),
> + name => {
> + type => 'string',
> + pattern => PVE::Ceph::Services::SERVICE_REGEX,
> + description => 'The name (ID) of the mds',
> + },
> + },
> + },
> + returns => {
> + type => "object",
please actually describe the return format for such simple api calls
> + },
> + code => sub {
> + my ($param) = @_;
> +
> + PVE::Ceph::Tools::check_ceph_inited();
> +
> + my $name = $param->{name};
> + my $rados = PVE::RADOS->new();
> +
> + my $result = {
> + ok_to_stop => 0,
> + status => '',
> + };
> +
> + my $code;
> + my $status;
> + eval {
> + ($code, $status) = $rados->mon_command({ prefix => 'mds ok-to-stop', format => 'plain', ids => [ $name ] }, 1);
> + };
eval's return their last expression (which can but doesn has to use a trailing semicolon)
so you could do:
my ($code, $status) = eval {
$rados->mon_command(...)
};
> + die $@ if $@;
ok, why bother with eval'ing if you die 1:1 in any error case anyway??
> +
> + $result->{ok_to_stop} = $code == 0 ? 1 : 0;
> + $result->{status} = $status;
for such simple logic we can avoid the intermediate $result and return directly,
that shaves off about 6 lines from this api call and please also use the kebab-case
for new properties, both in input parameters or output result.
return {
'ok-to-stop' => $code == 0 ? 1 : 0,
status => $status,
};
> +
> + return $result;
> + }});
> +
> 1;
next prev parent reply other threads:[~2022-02-22 8:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-18 11:38 [pve-devel] [PATCH librados2-perl manager 0/6] Add Ceph safety checks Aaron Lauterer
2022-02-18 11:38 ` [pve-devel] [PATCH librados2-perl 1/6] mon_command: free outs buffer Aaron Lauterer
2022-02-21 15:35 ` Thomas Lamprecht
2022-02-18 11:38 ` [pve-devel] [PATCH librados2-perl 2/6] mon_command: optionally ignore errors and return hashmap Aaron Lauterer
2022-02-21 15:44 ` Thomas Lamprecht
2022-02-22 12:42 ` Aaron Lauterer
2022-02-18 11:38 ` [pve-devel] [PATCH manager 3/6] api: osd: force mon_command to scalar context Aaron Lauterer
2022-02-18 11:38 ` [pve-devel] [PATCH manager 4/6] api: mon: mds: osd: add safety check endpoints Aaron Lauterer
2022-02-22 8:44 ` Thomas Lamprecht [this message]
2022-03-14 16:49 ` Aaron Lauterer
2022-03-14 17:02 ` Thomas Lamprecht
2022-02-18 11:38 ` [pve-devel] [PATCH manager 5/6] ui: osd: warn if removal could be problematic Aaron Lauterer
2022-02-24 12:46 ` Thomas Lamprecht
2022-02-18 11:38 ` [pve-devel] [PATCH manager 6/6] ui: osd: mon: mds: warn if stop/destroy actions are problematic Aaron Lauterer
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=d3fb75b3-7b08-51a1-1c53-35ab743efaa9@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=a.lauterer@proxmox.com \
--cc=pve-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