public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Stefan Hanreich <s.hanreich@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
	Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Gabriel Goller <g.goller@proxmox.com>
Subject: Re: [pve-devel] [PATCH pve-manager 1/1] cli: add pveeth
Date: Tue, 15 Jul 2025 16:06:11 +0200	[thread overview]
Message-ID: <6836b503-698d-42e5-8f29-a0502c0262a7@proxmox.com> (raw)
In-Reply-To: <4495c12f-da09-4469-a507-de90cced1ba3@proxmox.com>



On 7/15/25 15:51, Thomas Lamprecht wrote:
> Am 15.07.25 um 14:30 schrieb Stefan Hanreich:
>>>> This I'd need to think through, just wanted to comment on above before
>>>> I forget.
>>>
>>> If we really want to make pin and unpin involutive, we would need to
>>> store somewhere the interface names or store the interface naming
>>> policy.
>>
>> unpin was more intended as a solution for users that made an error with
>> invoking the pin command and give them an easy way to revert the changes
>> generated by pin. In the other thread with Dominik I've also discussed a
>> different approach on how to handle applying the configuration. Solving
>> it as follows would also introduce a way of reverting the configuration:
>>
>> * 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.
>>
>> If we solve it like this, then we could introduce a 'revert' or
>> 'rollback' command, which would simply delete any pending changes and
>> then remove the generated link files. We'd have three possible actions
>> for handling pending configuration files:
>>
>> * generate (generates the pending configuration)
>> * apply (which applies pending configuration)
>> * revert/rollback (which removes any pending configuration changes)
>>
>> This would reset everything to the way it was before generating the
>> pending configuration. It would also obsolete a dry-run flag imo, since
>> we have the intermediate, pending, configuration that needs to be
>> manually applied. Users can use those for inspecting the potential changes.
>>
>> It would still make sense to provide the opportunity for users to get
>> rid of all pinned names, which unpin in its current state could then do.
> That would be certainly nice to have for admins, but it would also
> be nice if firewall stack can still transparently cope with the altnames.

It can - with the patches included in this series.

> btw. a reboot in the "pinned but not applied" state might need some
> special handling to, because IIRC it would now apply the /e/n/i changes
> but not the firewall rules.
> We could add the handling for the node firewall rules in the apply /e/n/i
> endpoint, as then it might work automagically?

I can look into that, then this might be the best way forward, if I can
move it there easily.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


  reply	other threads:[~2025-07-15 14:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-09 19:45 [pve-devel] [RFC common/firewall/manager/network/proxmox{-ve-rs, -firewall} 0/7] NIC renaming mitigations Stefan Hanreich
2025-07-09 19:45 ` [pve-devel] [PATCH pve-common 1/2] network: add ip link and altname helpers Stefan Hanreich
2025-07-09 19:45 ` [pve-devel] [PATCH pve-common 2/2] network: add nic prefix to physical nic regex Stefan Hanreich
2025-07-09 19:45 ` [pve-devel] [PATCH proxmox-ve-rs 1/1] config: ip link struct Stefan Hanreich
2025-07-09 19:45 ` [pve-devel] [PATCH proxmox-firewall 1/1] firewall: add altname support for firewall rules Stefan Hanreich
2025-07-09 19:45 ` [pve-devel] [PATCH pve-firewall 1/1] firewall: add altname support Stefan Hanreich
2025-07-09 19:45 ` [pve-devel] [PATCH pve-network 1/1] controllers: isis: " Stefan Hanreich
2025-07-09 19:45 ` [pve-devel] [PATCH pve-manager 1/1] cli: add pveeth Stefan Hanreich
2025-07-10 14:53   ` Gabriel Goller
2025-07-10 15:08     ` Thomas Lamprecht
2025-07-10 16:25       ` Gabriel Goller
2025-07-15 12:30         ` Stefan Hanreich
2025-07-15 12:35           ` Stefan Hanreich
2025-07-15 13:51           ` Thomas Lamprecht
2025-07-15 14:06             ` Stefan Hanreich [this message]
2025-07-15 15:02             ` Stefan Hanreich
2025-07-16 15:19 ` [pve-devel] superseded: [RFC common/firewall/manager/network/proxmox{-ve-rs, -firewall} 0/7] NIC renaming mitigations Stefan Hanreich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6836b503-698d-42e5-8f29-a0502c0262a7@proxmox.com \
    --to=s.hanreich@proxmox.com \
    --cc=g.goller@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=t.lamprecht@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal