[pve-devel] [PATCH pve-manager v2 1/1] api/ui: show/return alternative interface names

[Dominik Csapak]

On 7/15/25 11:41, Stefan Hanreich wrote:
> On 7/15/25 11:30, Dominik Csapak wrote:
>> On 7/15/25 11:21, Stefan Hanreich wrote:
>>> Was formulating my response to v1, but you were too fast with sending a
>>> v2 for me. I think we need to also consider the case where we pinned and
>>> replaced the names in /e/n/i via pveeth already, but the changes to the
>>> network interface names haven't yet been applied. The problem here is
>>> that we also return interfaces contained in /proc/net/dev in the
>>> overview as well [1] - which would lead to duplicate interface names in
>>> the view.
>>>
>>> I considered applying the changes to the network interface names
>>> immediately via `udevadm trigger`. Alternatively, I thought of adding
>>> the old names as altnames when pinning network interfaces, but not in a
>>> persistent manner. I think both would solve this state between
>>> transitioning from the old names to the new names. What do you think?
>>
>>
>> ok, so from what i can tell 'pveeth pin' writes directly into the /e/n/i
>> file?
>> shouldn't it write to /e/n/i.new file (or whatever it's named) so we
>> show it as pending change?
> 
> Currently yes, but I am still considering what would be the best way
> forward. I think you could make an argument for both. The problem is
> that while we have this mechanism of a temporary configuration file for
> /etc/network/interfaces and SDN, we do not have one for the firewall
> configuration. There is a dry_run functionality in pveeth, but it just
> generates the files in a different location.
> 
> It might make more sense to implement it as a two-step process:
> 
> * Pinning generates the new configuration files in the pending config of
> /e/n/i and SDN. For the firewall we'd have to create one as well and
> probably just handle this manually in the following step.
> 
> * Add another command that applies the temporary changes which would
> also include applying the changes via udevadm immediately.
> 
> Then users could inspect the generated changes via our UI (at least for
> Network / SDN). This would then also allow us to remove the dry_run
> functionality, since it would be implicitly included in this create /
> apply process. It would also solve the issue with this weird limbo state.
> 
> I'm just unsure on how we could integrate showing the changes to the FW
> configuration in a nice way.

mhmm on the spot i'd probably say we could color code the fw rule changes
(e.g. yellow for pending changed, red for pending removed, etc.)
maybe also a seperate column with that info as text/symbol
> 
>> then we could do the udevadm trigger in the 'apply config' api handler?
>>
>> also, basically the 'altname' lookup code would also have to lookup the
>> .link files ? (seems like it's a lot of work/disk reading to do?)
> 
> Yes, exactly - hence why I considered adding them as an altname since
> this would save us this procedure of parsing *all* link files in order
> to be able to generate a sensible view of /e/n/i.

ah ok, so you'd do 'ip link property add dev ensX altname nic0' ?
that way you could immediately add that too for the new name, no?

when you'd do that, we would not need to parse the link files
in the api code, since ip would already have that info ?