From: Dominik Csapak <d.csapak@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Aaron Lauterer <a.lauterer@proxmox.com>
Subject: Re: [pve-devel] [RFC manager 2/4] pveceph: add management for erasure code rules
Date: Wed, 27 Apr 2022 15:32:20 +0200 [thread overview]
Message-ID: <b6cf5f50-3d4f-8793-5995-41e39bca1fb7@proxmox.com> (raw)
In-Reply-To: <20220408101416.165312-3-a.lauterer@proxmox.com>
some comments inline
On 4/8/22 12:14, Aaron Lauterer wrote:
> Allow to set 'k' and 'm' values and optionally the device class and
> failure domains.
> Implemented in a way that also exposes the functionality via the API.
>
> Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
> ---
> PVE/API2/Ceph.pm | 6 +
> PVE/API2/Ceph/ECProfiles.pm | 249 ++++++++++++++++++++++++++++++++++++
> PVE/API2/Ceph/Makefile | 1 +
> PVE/CLI/pveceph.pm | 12 ++
> 4 files changed, 268 insertions(+)
> create mode 100644 PVE/API2/Ceph/ECProfiles.pm
>
> diff --git a/PVE/API2/Ceph.pm b/PVE/API2/Ceph.pm
> index 3bbcfe4c..06bd2e2e 100644
> --- a/PVE/API2/Ceph.pm
> +++ b/PVE/API2/Ceph.pm
> @@ -24,6 +24,7 @@ use PVE::API2::Ceph::MDS;
> use PVE::API2::Ceph::MGR;
> use PVE::API2::Ceph::MON;
> use PVE::API2::Ceph::Pools;
> +use PVE::API2::Ceph::ECProfiles;
> use PVE::API2::Storage::Config;
>
> use base qw(PVE::RESTHandler);
> @@ -60,6 +61,11 @@ __PACKAGE__->register_method ({
> path => 'pools',
> });
>
> +__PACKAGE__->register_method ({
> + subclass => "PVE::API2::Ceph::ECProfiles",
> + path => 'ecprofiles',
> +});
> +
> __PACKAGE__->register_method ({
> name => 'index',
> path => '',
> diff --git a/PVE/API2/Ceph/ECProfiles.pm b/PVE/API2/Ceph/ECProfiles.pm
> new file mode 100644
> index 00000000..f7c51845
> --- /dev/null
> +++ b/PVE/API2/Ceph/ECProfiles.pm
> @@ -0,0 +1,249 @@
> +package PVE::API2::Ceph::ECProfiles;
> +
> +use strict;
> +use warnings;
> +
> +use PVE::Ceph::Tools;
> +use PVE::Ceph::Services;
> +use PVE::JSONSchema qw(get_standard_option);
> +use PVE::RADOS;
> +use PVE::RESTHandler;
> +use PVE::RPCEnvironment;
> +use PVE::Tools qw(extract_param);
> +
> +use base qw(PVE::RESTHandler);
> +
> +__PACKAGE__->register_method ({
> + name => 'lsecprofile',
> + path => '',
> + method => 'GET',
> + description => "List erasure coding (EC) profiles",
> + proxyto => 'node',
> + protected => 1,
> + permissions => {
> + check => ['perm', '/', [ 'Sys.Audit', 'Datastore.Audit' ], any => 1],
> + },
> + parameters => {
> + additionalProperties => 0,
> + properties => {
> + node => get_standard_option('pve-node'),
> + },
> + },
> + returns => {
> + type => 'array',
> + items => {
> + type => "object",
> + properties => {
> + name => {
> + type => 'string',
> + title => 'Name',
> + },
> + },
> + },
> + },
> + code => sub {
> + my ($param) = @_;
> +
> + PVE::Ceph::Tools::check_ceph_configured();
> +
> + my $rados = PVE::RADOS->new();
> + my $profiles = $rados->mon_command({ prefix => 'osd erasure-code-profile ls' });
> + my $res = [];
> + foreach my $profile (@$profiles) {
> + push @$res, { name => $profile };
> + }
would that not be a simple
map { { name => $_ } } @$profiles;
?
> + return $res;
> + }});
> +
> +
> +__PACKAGE__->register_method ({
> + name => 'getecprofile',
> + path => '{name}',
> + method => 'GET',
> + description => "List erasure coding (EC) profiles",
> + proxyto => 'node',
> + protected => 1,
> + permissions => {
> + check => ['perm', '/', [ 'Sys.Audit', 'Datastore.Audit' ], any => 1],
> + },
> + parameters => {
> + additionalProperties => 0,
> + properties => {
> + node => get_standard_option('pve-node'),
> + name => {
> + type => 'string',
> + description => "The name of the erasure code profile.",
> + },
> + },
> + },
> + returns => {
> + type => 'object',
> + properties => {
> + name => { type => 'string', title => 'Name' },
> + m => { type => 'integer', title => 'm' },
> + k => { type => 'integer', title => 'k' },
> + plugin => { type => 'string', title => 'plugin' },
> + technique => { type => 'string', title => 'Technique' },
> + w => { type => 'integer', title => 'w', optional => 1 },
> + 'crush-root' => {
> + type => 'string',
> + title => 'Crush root',
> + optional => 1,
> + },
> + 'crush-device-class' => {
> + type => 'string',
> + title => 'Device Class',
> + optional => 1,
> + },
> + 'crush-failure-domain' => {
> + type => 'string',
> + title => 'Failure Domain',
> + optional => 1,
> + },
> + 'jerasure-per-chunk-alignment' => {
> + type => 'string',
> + title => 'jerasure-per-chunk-alignment',
> + optional => 1,
> + },
nit: i am not really a fan of the indenation/aligning here... especially the mixing of the inlining
> + },
> + },
> + code => sub {
> + my ($param) = @_;
> +
> + PVE::Ceph::Tools::check_ceph_configured();
> +
> + my $rados = PVE::RADOS->new();
> + my $res = $rados->mon_command({
> + prefix => 'osd erasure-code-profile get',
> + name => $param->{name},
> + });
> +
> + my $data = {
> + name => $param->{name},
> + 'crush-root' => $res->{'crush-root'},
> + w => $res->{w},
> + m => $res->{m},
> + k => $res->{k},
> + 'crush-device-class' => $res->{'crush-device-class'},
> + 'crush-failure-domain' => $res->{'crush-failure-domain'},
> + plugin => $res->{'plugin'},
> + 'jerasure-per-chunk-alignment' => $res->{'jerasure-per-chunk-alignment'},
> + technique => $res->{'technique'},
> + };
i don't think the aligning here makes it much more readable..
aside from that, why not simply using the $res ?
is there more here that we may want?
if not, how about having a list of 'whitelisted' props and doing
for my $prop (qw(name crush-root w m k ...)) {
$data->{$prop} = $res->{$prop};
}
we could even factor out the return schema and reuse that ?
for my $prop (keys %$return_schema) {
...
}
> + return $data;
> + }});
> +
> +
> +__PACKAGE__->register_method ({
> + name => 'createecprofile',
> + path => '',
> + method => 'POST',
> + description => "Create erasure code profile",
> + proxyto => 'node',
> + protected => 1,
> + permissions => {
> + check => ['perm', '/', [ 'Sys.Modify' ]],
> + },
> + parameters => {
> + additionalProperties => 0,
> + properties => {
> + node => get_standard_option('pve-node'),
> + name => {
> + description => 'The name of the erasure code profile. Must be unique.',
> + type => 'string',
> + },
> + k => {
> + type => 'integer',
> + description => 'Number of data chunks.',
> + },
> + m => {
> + type => 'integer',
> + description => 'Number of coding chunks.',
> + },
> + 'failure-domain' => {
> + type => 'string',
> + optional => 1,
> + description => "CRUSH failure domain. Default is 'host'",
> + },
> + 'device-class' => {
> + type => 'string',
> + optional => 1,
> + description => "CRUSH device class.",
> + },
> + },
> + },
i guess this is not complete because of the rfc?
there are no formats defined and no limits whatsoever (k/m should have a minimum i guess)
also the strings should be limited somewhat and the default (for failure-domain)
can be in the schema itself too
because of this i can create an ecprofile '0' that i cannot use ;)
> + returns => { type => 'string' },
> + code => sub {
> + my ($param) = @_;
> +
> + PVE::Ceph::Tools::check_ceph_configured();
> +
> + my $failuredomain = $param->{'failure-domain'} // 'host';
> +
> + my $rpcenv = PVE::RPCEnvironment::get();
> + my $user = $rpcenv->get_user();
> +
> + my $profile = [
> + "crush-failure-domain=${failuredomain}",
> + "k=$param->{k}",
> + "m=$param->{m}",
> + ];
> +
> + push(@$profile, "crush-device-class=$param->{'device-class'}") if $param->{'device-class'};
> +
> + my $worker = sub {
> + my $rados = PVE::RADOS->new();
> + $rados->mon_command({
> + prefix => 'osd erasure-code-profile set',
> + name => $param->{name},
> + profile => $profile,
> + });
> + };
> +
> + return $rpcenv->fork_worker('cephcreateecprofile', $param->{name}, $user, $worker);
> + }});
> +
> +
> +__PACKAGE__->register_method ({
> + name => 'destroyecprofile',
> + path => '{name}',
> + method => 'DELETE',
> + description => "Destroy erasure code profile",
> + proxyto => 'node',
> + protected => 1,
> + permissions => {
> + check => ['perm', '/', [ 'Sys.Modify' ]],
> + },
> + parameters => {
> + additionalProperties => 0,
> + properties => {
> + node => get_standard_option('pve-node'),
> + name => {
> + description => 'The name of the erasure code profile.',
> + type => 'string',
> + },
> + },
> + },
> + returns => { type => 'string' },
> + code => sub {
> + my ($param) = @_;
> +
> + PVE::Ceph::Tools::check_ceph_configured();
> +
> + my $rpcenv = PVE::RPCEnvironment::get();
> + my $user = $rpcenv->get_user();
> +
> + my $worker = sub {
> + my $rados = PVE::RADOS->new();
> + $rados->mon_command({
> + prefix => 'osd erasure-code-profile rm',
> + name => $param->{name},
> + format => 'plain',
> + });
> + };
should there not be some checks if there is still some pool using that?
or do we want to fallback to the ceph error (if there is one?)
> +
> + return $rpcenv->fork_worker('cephdestroyecprofile', $param->{name}, $user, $worker);
> + }});
> +
> +
> +1;
> diff --git a/PVE/API2/Ceph/Makefile b/PVE/API2/Ceph/Makefile
> index 45daafda..c0d8135a 100644
> --- a/PVE/API2/Ceph/Makefile
> +++ b/PVE/API2/Ceph/Makefile
> @@ -6,6 +6,7 @@ PERLSOURCE= \
> OSD.pm \
> FS.pm \
> Pools.pm \
> + ECProfiles.pm \
> MDS.pm
>
> all:
> diff --git a/PVE/CLI/pveceph.pm b/PVE/CLI/pveceph.pm
> index 995cfcd5..839df9a3 100755
> --- a/PVE/CLI/pveceph.pm
> +++ b/PVE/CLI/pveceph.pm
> @@ -370,6 +370,18 @@ our $cmddef = {
> PVE::CLIFormatter::print_api_result($data, $schema, undef, $options);
> }, $PVE::RESTHandler::standard_output_options],
> },
> + ecprofile => {
> + ls => ['PVE::API2::Ceph::ECProfiles', 'lsecprofile', [], {node => $nodename}, sub {
> + my ($data, $schema, $options) = @_;
> + PVE::CLIFormatter::print_api_result($data, $schema,[ 'name' ], $options);
> + }, $PVE::RESTHandler::standard_output_options],
> + create => ['PVE::API2::Ceph::ECProfiles', 'createecprofile', ['name', 'k', 'm'], { node => $nodename } ],
> + destroy => [ 'PVE::API2::Ceph::ECProfiles', 'destroyecprofile', ['name'], { node => $nodename } ],
> + get => [ 'PVE::API2::Ceph::ECProfiles', 'getecprofile', ['name'], { node => $nodename }, sub {
> + my ($data, $schema, $options) = @_;
> + PVE::CLIFormatter::print_api_result($data, $schema, undef, $options);
> + }, $PVE::RESTHandler::standard_output_options],
> + },
> lspools => { alias => 'pool ls' },
> createpool => { alias => 'pool create' },
> destroypool => { alias => 'pool destroy' },
next prev parent reply other threads:[~2022-04-27 13:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-08 10:14 [pve-devel] [RFC manager 0/4] Ceph add basic erasure code pool mgmt support Aaron Lauterer
2022-04-08 10:14 ` [pve-devel] [PATCH manager 1/4] api: ceph: $get_storages check if data-pool too Aaron Lauterer
2022-04-08 10:14 ` [pve-devel] [RFC manager 2/4] pveceph: add management for erasure code rules Aaron Lauterer
2022-04-27 13:32 ` Dominik Csapak [this message]
2022-04-08 10:14 ` [pve-devel] [RFC manager 3/4] ceph tools: add check if erasure code profile exists Aaron Lauterer
2022-04-08 10:14 ` [pve-devel] [PATCH manager 4/4] ceph pools: allow to create erasure code pools Aaron Lauterer
2022-04-27 13:32 ` Dominik Csapak
2022-04-08 11:13 ` [pve-devel] [RFC manager 0/4] Ceph add basic erasure code pool mgmt support Aaron Lauterer
2022-04-27 13:37 ` Dominik Csapak
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=b6cf5f50-3d4f-8793-5995-41e39bca1fb7@proxmox.com \
--to=d.csapak@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 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.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal