public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH v2 firewall 6/6] simulator: use new bridge naming scheme
Date: Mon, 26 Feb 2024 16:36:59 +0100	[thread overview]
Message-ID: <44dc4d0b-6607-41cd-81f4-f45beac212a0@proxmox.com> (raw)
In-Reply-To: <mailman.235.1708944723.434.pve-devel@lists.proxmox.com>

Am 26/02/2024 um 11:51 schrieb DERUMIER, Alexandre via pve-devel:
> hi,I think you should limit to 8 characters like for sdn vnet, 
> 
> as we need to space to  vlan tag for example (vmbrY.XXXX), or other sdn
> construct.

alternatively just show a hint in the UI if longer than 8 characters
and, if possible, error out with a clear message when one sets up
something that cannot work any more.

Not all users use those features, as long as they are made aware of
implications it can be fine to allow cases that do not allow every
possible feature.

That said, starting out with a 8 characters max length limit is quicker
to implement and would be fine for me.

Either using a common constant, or at least throw in a comment, and a
note in the commit message, with the reason for that limit, and that
it is shared between SDN vnets would be great though.

btw. one could also lift the strict naming scheme for bonds using
the 'bond-mode' flag to detect them.

Oh, and fwiw, having some awareness safety net like:

warn "..." if !defined $d->{'bridge_ports'} && $iface =~ m/^vmbr\d+$/;

for at least this major release could be nice to catch odd setups easier,
as IIRC that property really is required for ifupdown2 to consider an
interface as a bridge. Only this major release as then pve8to9 could
take over on warning for this and afterwards the admin either corrected
it or it's done by choice.




  parent reply	other threads:[~2024-02-26 15:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-23 14:36 [pve-devel] [PATCH v2 common/docs/widget-toolkit/manager/firewall 0/6] drop vmbr prefix for bridges Stefan Hanreich
2024-02-23 14:36 ` [pve-devel] [PATCH v2 common 1/6] interfaces: allow arbitrary bridge names in network config Stefan Hanreich
2024-02-23 14:36 ` [pve-devel] [PATCH v2 docs 2/6] network: update specification for bridge names Stefan Hanreich
2024-02-23 14:36 ` [pve-devel] [PATCH v2 widget-toolkit 3/6] network: allow bridges to have any valid interface name Stefan Hanreich
2024-02-23 14:36 ` [pve-devel] [PATCH v2 manager 4/6] sdn: qinq: vlan: properly validate bridge name Stefan Hanreich
2024-02-23 14:36 ` [pve-devel] [PATCH v2 manager 5/6] sdn: vlan: fix indentation in vlan edit dialogue Stefan Hanreich
2024-02-23 14:36 ` [pve-devel] [PATCH v2 firewall 6/6] simulator: use new bridge naming scheme Stefan Hanreich
     [not found]   ` <mailman.235.1708944723.434.pve-devel@lists.proxmox.com>
2024-02-26 15:36     ` Thomas Lamprecht [this message]
2024-02-27 12:35       ` Stefan Hanreich
2024-02-28  9:35         ` Thomas Lamprecht

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=44dc4d0b-6607-41cd-81f4-f45beac212a0@proxmox.com \
    --to=t.lamprecht@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