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

[Stefan Hanreich]

On 7/15/25 12:33, Dominik Csapak wrote:
> 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

Yeah, I'll have to check how complicated that would be to implement -
particularly when the two firewall rulesets start to diverge. But having
a temporary firewall configuration similar to how /e/n/i or SDN works,
was something that we wanted to explore anyway - so that could actually
be a good starting point for that.

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

Yes, that was one of the solutions I had in mind, and that would be
quite convenient for that case if we do not immediately apply the changes.