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

[Stefan Hanreich]

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.

> 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.