From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <t.lamprecht@proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits))
(No client certificate requested)
by lists.proxmox.com (Postfix) with ESMTPS id A3DAD8A215
for <pve-devel@lists.proxmox.com>; Wed, 19 Oct 2022 07:49:36 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id 7D8C6310A6
for <pve-devel@lists.proxmox.com>; Wed, 19 Oct 2022 07:49:06 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
[94.136.29.106])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits))
(No client certificate requested)
by firstgate.proxmox.com (Proxmox) with ESMTPS
for <pve-devel@lists.proxmox.com>; Wed, 19 Oct 2022 07:49:05 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
by proxmox-new.maurer-it.com (Proxmox) with ESMTP id C2D4244A76
for <pve-devel@lists.proxmox.com>; Wed, 19 Oct 2022 07:49:04 +0200 (CEST)
Message-ID: <ca40adda-2eb5-a01a-83f5-a511f17fb1c5@proxmox.com>
Date: Wed, 19 Oct 2022 07:49:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:106.0) Gecko/20100101
Thunderbird/106.0
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Daniel Tschlatscher <d.tschlatscher@proxmox.com>
References: <20221017135632.569782-1-d.tschlatscher@proxmox.com>
Content-Language: en-GB
In-Reply-To: <20221017135632.569782-1-d.tschlatscher@proxmox.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results: 0
AWL -0.034 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
NICE_REPLY_A -0.001 Looks like a legit reply (A)
SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record
SPF_PASS -0.001 SPF: sender matches SPF record
Subject: Re: [pve-devel] [PATCH manager 1/2] fix #3719: gui: expose MTU
option for containers in web UI
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Wed, 19 Oct 2022 05:49:36 -0000
the implementation looks mostly OK and works, but some comments on limits and
also a workflow nit that require a v2
high level: The CT implementation currently doesn't checks limits like
qemu-server does, like setting (most of the time) bogus values <576 (see below)
and guaranteed not working values like > $bridge_mtu.
So I'd also add the overall limit of 2^16-1 there as upper limit in the schema
and also assert <= $bridge_mtu on CT-start/veth-hotplug and possibly also on
config change (to early catch it for stopped CTs already, as IMO its better to
push the user towards setting the bridge MTU earlier than the ones of its
connected ports.
work flow nit: why bother adding this to the non advanced section only to move
it immediately? I'd directly add it to advancedColumn1, if you want to move out
rate limit field before or after is
Am 17/10/2022 um 15:56 schrieb Daniel Tschlatscher:> The option to set the mtu parameter for lxc containers already exists
> in the backend. It only had to be exposed in the web UI as well.
>
> Signed-off-by: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
> ---
> www/manager6/lxc/Network.js | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/www/manager6/lxc/Network.js b/www/manager6/lxc/Network.js
> index 7b6437c5..d6a35a49 100644
> --- a/www/manager6/lxc/Network.js
> +++ b/www/manager6/lxc/Network.js
> @@ -138,6 +138,14 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
> name: 'firewall',
> value: cdata.firewall,
> },
> + {
> + xtype: 'proxmoxintegerfield',
> + fieldLabel: gettext('MTU'),
wouldn't gettext that, this is a technical abbreviation that is known widely
enough to be language agnostic.
> + name: 'mtu',
> + value: cdata.mtu,
needs an emptyText with the default behavior if not set, something like:
"Same as Bridge"
> + minValue: 64,
IP requires that hosts must be able to process IP datagrams of at least 576
bytes (for IPv4) or 1280 bytes (for IPv6).
And while yes, one may use something different than IP for sending ethernet
link stuff it seems rather unlikely in practice, so maybe go for 576 as min, if
someone complains we can still lower that and then have an actual known use
case.
The backend can stay at 64 for now, as there we would need to wait for the next
major release with a check for < 576 added to the pve7to8 upgrade helper
script, as long as the frontend is restrictive from the beginning I think there
won't be many cases that run into this check though.