Re: [pve-devel] applied: [PATCH pve-common 1/1] inotify/interfaces: use 'ip link' instead of /proc/net/dev

[Stefan Hanreich <s.hanreich@proxmox.com>]

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