[pve-devel] [PATCH v2 firewall 6/6] simulator: use new bridge naming scheme

[Thomas Lamprecht]

Am 27/02/2024 um 13:35 schrieb Stefan Hanreich:
> On Mon, Feb 26, 2024 at 04:36:59PM +0100, Thomas Lamprecht wrote:
>> 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.
>> [...]
>> That said, starting out with a 8 characters max length limit is quicker
>> to implement and would be fine for me.
> 
> When creating a VNet with this patch, the Web UI should validate that
> the bridge name isn't longer than 10 characters, so it should be fine
> since .XXXX is at most 5 characters - or am I missing something?
> 
> Should be no problem to switch from 10 to 8 though, if this is solely
> for possible future additions that might require more than 5
> characters.
> 
> Might be a bit awkward  if a user creates a bridge with >10 characters
> and then notices he cannot use it as a bridge in SDN.

yeah that's why I'd show a hint that makes users aware that their
current name length is not ideal for maximum feature compat, but as
said, no hard feelings going for just 10 as maximum is fine; I for
one often want shorter names anyway (brX instead of vmbrX ^^

>> btw. one could also lift the strict naming scheme for bonds using
>> the 'bond-mode' flag to detect them.
> 
> Yes, definitely something I could introduce but we would need some
> solution for the pve-firewall simulator, since it only goes off of
> naming schemes rather than the interfaces file.

meh, that's really limited...  either check the real world, e.g.,
for bridges if /sys/class/net/$iface/bridge exists or via ethtool,
or make the user provide that info, best would be probably a mix
of both, existing interfaces are detected and others need to be
manually specified (e.g., via CLI option map --iface $name:$type
or the like)

>> Oh, and fwiw, having some awareness safety net like:
>>
>> warn "..." if !defined $d->{'bridge_ports'} && $iface =~ m/^vmbr\d+$/;
> 
> Sounds good, you mean in the parsing of the interface file - I assume?
> 

yes, while that will be noisy, it's fine in this case.