public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Thomas Lamprecht <t.lamprecht@proxmox.com>
Subject: Re: [pve-devel] [PATCH common 2/2] schema: add pve-bridge-id option/format/pair
Date: Fri, 16 Apr 2021 12:10:33 +0200	[thread overview]
Message-ID: <1618567700.qph1jxvqr7.astroid@nora.none> (raw)
In-Reply-To: <3c95a4c6-0403-799f-fe39-c4ae241eb654@proxmox.com>

On April 16, 2021 11:53 am, Thomas Lamprecht wrote:
> On 13.04.21 14:16, Fabian Grünbichler wrote:
>> for re-use in qemu-server/pve-container, which already have this option
>> duplicated. the '-pair' is needed for remote migration, but can also be
>> a nice addition to regular intra-cluster migration to lift the
>> restriction of having identically named bridges.
>> 
> 
> looks OK, one naming issue inline
> 
>> Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
>> ---
>>  src/PVE/JSONSchema.pm | 25 +++++++++++++++++++++++++
>>  1 file changed, 25 insertions(+)
>> 
>> diff --git a/src/PVE/JSONSchema.pm b/src/PVE/JSONSchema.pm
>> index f2ddb50..bf30b33 100644
>> --- a/src/PVE/JSONSchema.pm
>> +++ b/src/PVE/JSONSchema.pm
>> @@ -82,6 +82,12 @@ register_standard_option('pve-storage-id', {
>>      type => 'string', format => 'pve-storage-id',
>>  });
>>  
>> +register_standard_option('pve-bridge-id', {
>> +    description => "Bridge to attach guest network devices to.",
>> +    type => 'string', format => 'pve-bridge-id',
>> +    format_description => 'bridge',
>> +});
>> +
>>  register_standard_option('pve-config-digest', {
>>      description => 'Prevent changes if current configuration file has different SHA1 digest. This can be used to prevent concurrent modifications.',
>>      type => 'string',
>> @@ -193,6 +199,17 @@ sub parse_storage_id {
>>      return parse_id($storeid, 'storage', $noerr);
>>  }
>>  
>> +PVE::JSONSchema::register_format('pve-bridge-id', \&parse_bridge_id);
>> +sub parse_bridge_id {
>> +    my ($id, $noerr) = @_;
>> +
>> +    if ($id !~ m/^[-_.\w\d]+$/) {
>> +	return undef if $noerr;
>> +	die "invalid bridge ID '$id'\n";
>> +    }
>> +    return $id;
>> +}
>> +
>>  PVE::JSONSchema::register_format('acme-plugin-id', \&parse_acme_plugin_id);
>>  sub parse_acme_plugin_id {
>>      my ($pluginid, $noerr) = @_;
>> @@ -293,6 +310,14 @@ sub verify_storagepair {
>>      my ($storagepair, $noerr) = @_;
>>      return $verify_idpair->($storagepair, $noerr, 'pve-storage-id');
>>  }
>> +
>> +# note: this only checks a single list entry
>> +# when using a bridgepair-list map, you need to pass the full parameter to
>> +# parse_idmap
>> +register_format('bridgepair', \&verify_bridgepair);
> 
> pve-bridge-id vs. bridgepair seems slightly odd as syntax choice?
> 
> Why not `bridge-pair` or even `pve-bridge-pair`?

mainly because of the pre-existing 'storagepair', but I am fine with 
either (and also with changing storagepair - this series already touches 
so many repos that change can be mixed in without extra churn I think).

same for the API parameter(s) (I recycled the existing 'targetstorage', 
although I'd find 'target-FOO' more readable and I am also fine with 
using that variant for the new API call for all parameters)

> 
>> +sub verify_bridgepair {
>> +    my ($bridgepair, $noerr) = @_;
>> +    return $verify_idpair->($bridgepair, $noerr, 'pve-bridge-id');
>>  }
>>  
>>  register_format('mac-addr', \&pve_verify_mac_addr);
>> 
> 
> 




  reply	other threads:[~2021-04-16 10:11 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-13 12:16 [pve-devel] [RFC qemu-server++ 0/22] remote migration Fabian Grünbichler
2021-04-13 12:16 ` [pve-devel] [PATCH proxmox 1/2] websocket: make field public Fabian Grünbichler
2021-04-13 12:16 ` [pve-devel] [PATCH proxmox 2/2] websocket: adapt for client connection Fabian Grünbichler
2021-04-13 12:16 ` [pve-devel] [PATCH proxmox-websocket-tunnel 1/2] initial commit Fabian Grünbichler
2021-04-13 12:16 ` [pve-devel] [PATCH proxmox-websocket-tunnel 2/2] add tunnel implementation Fabian Grünbichler
2021-04-13 12:16 ` [pve-devel] [PATCH access-control 1/2] tickets: add tunnel ticket Fabian Grünbichler
2021-04-13 12:16 ` [pve-devel] [PATCH access-control 2/2] ticket: normalize path for verification Fabian Grünbichler
2021-04-13 12:16 ` [pve-devel] [PATCH cluster 1/4] remote.cfg: add new config file Fabian Grünbichler
2021-04-13 12:16 ` [pve-devel] [PATCH cluster 2/4] add get_remote_info Fabian Grünbichler
2021-04-18 17:07   ` Thomas Lamprecht
2021-04-19  7:48     ` Fabian Grünbichler
2021-04-13 12:16 ` [pve-devel] [PATCH cluster 3/4] remote: add option/completion Fabian Grünbichler
2021-04-13 12:16 ` [pve-devel] [PATCH cluster 4/4] get_remote_info: also return FP if available Fabian Grünbichler
2021-04-13 12:16 ` [pve-devel] [PATCH common 1/2] schema: pull out abstract 'id-pair' verifier Fabian Grünbichler
2021-04-16 10:24   ` [pve-devel] applied: " Thomas Lamprecht
2021-04-19  8:43     ` [pve-devel] [PATCH common] fixup: remove double braces Stefan Reiter
2021-04-19  9:56       ` [pve-devel] applied: " Thomas Lamprecht
2021-04-13 12:16 ` [pve-devel] [PATCH common 2/2] schema: add pve-bridge-id option/format/pair Fabian Grünbichler
2021-04-16  9:53   ` Thomas Lamprecht
2021-04-16 10:10     ` Fabian Grünbichler [this message]
2021-04-13 12:16 ` [pve-devel] [PATCH guest-common] migrate: handle migration_network with remote migration Fabian Grünbichler
2021-04-13 12:16 ` [pve-devel] [PATCH manager] API: add node address(es) API endpoint Fabian Grünbichler
2021-04-16 10:17   ` Thomas Lamprecht
2021-04-16 11:37     ` Fabian Grünbichler
2021-04-13 12:16 ` [pve-devel] [PATCH storage] import: allow import from UNIX socket Fabian Grünbichler
2021-04-16 10:24   ` [pve-devel] applied: " Thomas Lamprecht
2021-04-13 12:16 ` [pve-devel] [PATCH qemu-server 1/7] migrate: factor out storage checks Fabian Grünbichler
2021-04-13 12:16 ` [pve-devel] [PATCH qemu-server 2/7] refactor map_storage to map_id Fabian Grünbichler
2021-04-13 12:16 ` [pve-devel] [PATCH qemu-server 3/7] schema: use pve-bridge-id Fabian Grünbichler
2021-04-13 12:16 ` [pve-devel] [PATCH qemu-server 4/7] mtunnel: add API endpoints Fabian Grünbichler
2021-04-13 12:16 ` [pve-devel] [PATCH qemu-server 5/7] migrate: refactor remote VM/tunnel start Fabian Grünbichler
2021-04-13 12:16 ` [pve-devel] [PATCH qemu-server 6/7] migrate: add remote migration handling Fabian Grünbichler
2021-04-13 12:16 ` [pve-devel] [PATCH qemu-server 7/7] api: add remote migrate endpoint Fabian Grünbichler
2021-04-15 14:04 ` [pve-devel] [RFC qemu-server++ 0/22] remote migration alexandre derumier
2021-04-15 14:32   ` Fabian Grünbichler
2021-04-15 14:36     ` Thomas Lamprecht
2021-04-15 16:38     ` Moula BADJI
2021-05-05  6:02       ` aderumier
2021-05-05  9:22         ` Dominik Csapak
2021-04-16  7:36     ` alexandre derumier

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=1618567700.qph1jxvqr7.astroid@nora.none \
    --to=f.gruenbichler@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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal