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>
Subject: Re: [pve-devel] [PATCH v2 common 1/4] fix #3893: network: make bridge vids configurable
Date: Fri, 10 Nov 2023 12:04:13 +0100	[thread overview]
Message-ID: <1699611727.xcoag2n7lq.astroid@yuna.none> (raw)
In-Reply-To: <20230614093033.820848-1-a.lauterer@proxmox.com>

On June 14, 2023 11:30 am, Aaron Lauterer wrote:
> For that we need to add a new format option that checks against valid
> VLAN tags and ranges, for example: 2 4 100-200
> 
> The check, if the default value should be used, needs to fail not just
> when not defined, but also in case it is an empty string.
> 
> Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
> ---
> no changes since v1.
> 
> I think replacing the 'defined' check with 'length' should be fine. We
> need to also handle the situation that the parameter is defined, but an
> empty string. There should be no autovivification happening. If I missed
> a side effect, let me know.
> 
> For the new format option I went with singular for the name as it only
> checks a single VLAN ID/range from the list, 'pve-bridge-vid', but I am
> not sure if it wouldn't be better to call it the actual parameter name
> 'pve-bridge-vids'.

I think the "count" of the name is fine, if at all, you might want to
add the "or range" part.

ifupdown2 calls the (full) format <number-comma-range-list> ;)

>  src/PVE/INotify.pm    |  2 +-
>  src/PVE/JSONSchema.pm | 32 ++++++++++++++++++++++++++++++++
>  2 files changed, 33 insertions(+), 1 deletion(-)
> 
> diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
> index bc33a8f..14f40ac 100644
> --- a/src/PVE/INotify.pm
> +++ b/src/PVE/INotify.pm
> @@ -1270,7 +1270,7 @@ sub __interface_to_string {
>  
>  	if (defined($d->{bridge_vlan_aware})) {
>  	    $raw .= "\tbridge-vlan-aware yes\n";
> -	    my $vlans = defined($d->{bridge_vids}) ? $d->{bridge_vids} : "2-4094";
> +	    my $vlans = length($d->{bridge_vids}) ? $d->{bridge_vids} : "2-4094";
>  	    $raw .= "\tbridge-vids $vlans\n";
>  	}
>  	$done->{bridge_vlan_aware} = 1;
> diff --git a/src/PVE/JSONSchema.pm b/src/PVE/JSONSchema.pm
> index 85d47f2..1051a45 100644
> --- a/src/PVE/JSONSchema.pm
> +++ b/src/PVE/JSONSchema.pm
> @@ -78,6 +78,12 @@ register_standard_option('pve-iface', {
>      minLength => 2, maxLength => 20,
>  });
>  
> +register_standard_option('pve-bridge-vid', {
> +    description => "Bridge VLAN ID.",
> +    type => 'string', format => 'pve-bridge-vid',
> +    minLength => 1, maxLength => 9,
> +});
> +
>  register_standard_option('pve-storage-id', {
>      description => "The storage identifier.",
>      type => 'string', format => 'pve-storage-id',
> @@ -588,6 +594,32 @@ sub pve_verify_iface {
>      return $id;
>  }
>  
> +# bridge vlan id (vids)
> +register_format('pve-bridge-vid', \&pve_verify_bridge_vid);
> +sub pve_verify_bridge_vid {
> +    my ($vlan, $noerr) = @_;
> +
> +    my $check_vid = sub {
> +	my $id = shift;
> +	if ( $id < 2 || $id > 4094) {

nit style (spacing around ())

> +	    return undef if $noerr;

this does not work - the undef would not be propagated up since you
don't check the return value below..

> +	    die "invalid VLAN tag '$id'\n";

tag vs ID - it's a bit weird that both are used interchangably..

> +	}
> +    };
> +
> +    if ($vlan !~ m/^(\d+)([-](\d+))?$/i) {
> +	return undef if $noerr;
> +	die "invalid VLAN configuration '$vlan'\n";
> +    }
> +    $check_vid->($1);
> +    if ($3) {
> +	$check_vid->($3);
> +	die "VLAN range must go from lower to higher tag '$vlan'" if $1 > $3 && !$noerr;
> +    }

not a huge fan of all the $N here.. could we get named variables please?
$start, $end; or $first, $last ;)

> +
> +    return $vlan;
> +}
> +
>  # general addresses by name or IP
>  register_format('address', \&pve_verify_address);
>  sub pve_verify_address {
> -- 
> 2.39.2
> 
> 
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> 
> 
> 




  parent reply	other threads:[~2023-11-10 11:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-14  9:30 Aaron Lauterer
2023-06-14  9:30 ` [pve-devel] [PATCH widget-toolkit 2/4] fix #3892: Network: add bridge vids field for bridge_vids Aaron Lauterer
2023-06-14  9:34   ` Aaron Lauterer
2023-11-10 11:03   ` Fabian Grünbichler
2023-06-14  9:30 ` [pve-devel] [PATCH v2 manager 3/4] fix #3893: api: network: add bridge_vids parameter Aaron Lauterer
2023-11-10 11:03   ` Fabian Grünbichler
2023-06-14  9:30 ` [pve-devel] [PATCH v2 manager 4/4] fix #3893: ui: network: enable bridge_vids field Aaron Lauterer
2023-09-29 13:37 ` [pve-devel] [PATCH v2 common 1/4] fix #3893: network: make bridge vids configurable Aaron Lauterer
2023-11-10 11:04 ` Fabian Grünbichler [this message]
2024-07-03  8:02 ` 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=1699611727.xcoag2n7lq.astroid@yuna.none \
    --to=f.gruenbichler@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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal