On 7/23/25 17:33, Thomas Lamprecht wrote:
> Am 23.07.25 um 17:16 schrieb Stefan Hanreich:
>> On 7/23/25 17:06, Thomas Lamprecht wrote:
>>
>> [snip]
>>
>>> I do not recall for sure anymore, but do differing bridge-ports work
>>> transparently with the ifupdown2 changes from Christoph. With that it might
>>> be
>>> nice to support it here too in the midterm, but that is certainly not a
>>> blocker
>>> for now.
>>
>> I'm not sure if I understand 100% - do you mean if the name used in
>> bridge-ports differs from the name of the referenced interface in
>> /e/n/i? That doesn't work currently, since the validation breaks.
>
> Yeah no, I mean does it work for ifupdown2 now? As every situation
> that works there but confuses our e/n/i parser is naturally not ideal
> (for the long term).
It does work there atm (just re-checked).
>> I've discussed this initially with Dominik today, and we'd need to
>> resolve altnames every time we look up names from bridge-ports, etc.
>
> That sounds like this is some expensive and high frequency operation,
> but isn't it really only required when managing the node network or
> wanting to do getting all available interfaces or doing some sanity
> checks, i.e. things that invovle parsing the network config, where we
> now have the altname map queried anyway?
>
> Or am I overlooking something?
I meant in the context of reading/writing the interfaces file. I haven't
100% thought it through, and I might be missing something critical, but
afaict it is as you said: We'd have to do it when reading / writing the
network configuration from /e/n/i and in the pve-manager Network API
when updating, since it does some additional checks (e.g.
check_duplicate_ports) before writing via the function in INotify.
>> If we want to support mixing names in the configuration, then we'd
>> additionally have to construct a temporary, merged, configuration and
>> validate against that.
>
> If ifupdown2 currently still doesn't supports that we're good in any
> case, if it supports it would be nice to keep our stack consistent with
> ifudpown2, but as hinted, not pressing now especially as our stack, as
> you mentioned, never creates such a mixed config anyway.
see above, fully supporting the current ifupdown2 capabilities will
require untangling.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
