From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id F037E1FF17E for ; Thu, 13 Nov 2025 16:08:46 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 1B7A0208FF; Thu, 13 Nov 2025 16:09:40 +0100 (CET) From: Stefan Hanreich To: pdm-devel@lists.proxmox.com Date: Thu, 13 Nov 2025 16:09:24 +0100 Message-ID: <20251113150934.611263-1-s.hanreich@proxmox.com> X-Mailer: git-send-email 2.47.3 MIME-Version: 1.0 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.177 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment KAM_LAZY_DOMAIN_SECURITY 1 Sending domain does not have any anti-forgery methods RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RDNS_NONE 0.793 Delivered to internal network by a host with no rDNS SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_NONE 0.001 SPF: sender does not publish an SPF Record Subject: [pdm-devel] [RFC proxmox{, -yew-comp, -datacenter-manager}/yew-mobile-gui v2 0/7] Add fallback variant to enum properties in Proxmox VE Rust API types X-BeenThere: pdm-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Datacenter Manager development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox Datacenter Manager development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pdm-devel-bounces@lists.proxmox.com Sender: "pdm-devel" ## Introduction This patch series adds a new fallback variant to all enums that are auto-generated in pve-api-types. This ensures that the addition of new enum variants in the Proxmox VE API does not break the deserialization of Proxmox VE API types in PDM. Rather, the unknown enum variant is now populated with the parsed enum variant name. For that matter this patch series introduces a new string type, FixedString. It can store up to 23 characters and is Copy, which is the main reason for introducing this custom string type. This lets us keep Copy in our generated enums. ## Open Questions ### Resubmitting unknown variants I had some off list discussions with Dominik and Dietmar regarding how consumers of the API (mainly the UI) could handle encountering unknown values when there is the possibility of re-submission of this data. Two main options emerged: * Resubmitting unknown values as-is, without preventing the user from doing so This has the upside of not preventing the user from submitting perfectly fine values if they haven't been implemented in PDM. An argument in favor would be that the PVE API should act as the last safeguard against invalid objects in the configuration anyway, so we could rely on PVE validation only in the case of unknown enums. The downside is that we need a round-trip to the Proxmox VE API and can only show the resulting error in the UI, without any validation. It also does not take care of situations where setting a certain, new, enum potentially requires special behavior when submitting values. * Showing the value, but preventing the user from re-submitting the value This is the safest option, since it prevents any, potentially destructive, action from the user due to the consumer not being aware of special . It also gives the user immediate feedback in the UI, without requiring a round-trip to the Proxmox VE instance, but of course users lose the ability to submit perfectly valid configurations (without upgrading). The answer is, of course, it depends on the context - but in the general case it seems preferable to me to show the value to the user, but prevent the user from re-submitting the value, since the UI cannot know if there is some special handling required in case the new enum variant is used in the UI. If there is a good argument for letting the user re-submit certain fields, then that seems like a fine option too, but imo *iff* there's good reasoning attached to it. What do you think? Any options that were missed? ### Storing unknown Variants When only reading and displaying / storing data, then including unknown values is desired behavior imo (again, in the general case) - since it allows storing data (e.g. metrics) that isn't yet understood but could potentially be understood perfectly fine after an upgrade of PDM. ### Unsafe FixedString I implemented as_bytes and as_str in FixedString via the unsafe variants of the methods and included tests that check for correct behavior of those methods. Using the safe variants and panicking here should be fine too imo if we don't want to go down that road. FixedString should only get used in rare, exceptional cases anyway - and even then not in a hot path. The adaption should be trivial. ## Adapting the existing code One difficulty when adapting the UI was identifying places in which a struct gets returned directly from the API, deserialized (but the value isn't used anywhere in the frontend), then serialized again and sent back to the backend. Since the FixedString serializes indistinguishable from a String, this could introduce situations where we submit unkown enum values when instead an error should be shown and the user prevented from submitting a form. I tried to look at each component in the backend / frontend and check if it uses and potentially re-submits am enum without checking its variants for unknown values. Since we model enums with checkboxes in the UI and have fixed values there, this should usually work and prevent users from submitting values that are unknown to the UI. Nevertheless, it's very much possible I missed some places, so here some group effort in trying to identify potentially problematic spots would be nice. ## Maintainers Notes pve-api-types breaks building: * proxmox-datacenter-manager * proxmox-yew-comp * pve-yew-mobile-gui proxmox-datacenter-manager and pve-yew-mobile-gui additionally need the newer version of proxmox-yew-comp to build. ## Changelog Changes from v1 (Thanks @Wolfgang): * remove truncate constructor * use macros to derive some of the traits by forwarding * cleaned up std::fmt imports * changed error type to zero-sized struct * add AsRef<[u8]> and Borrow impls * improved deserialize implementation proxmox: Stefan Hanreich (4): pve-api-types: add FixedString type pve-api-types: generate fallback variant for enums pve-api-types: regenerate pve-api-types: sdn: handle fallback variant pve-api-types/generator-lib/Schema2Rust.pm | 3 + pve-api-types/src/generated/types.rs | 210 ++++++++++++++++ pve-api-types/src/sdn.rs | 3 +- pve-api-types/src/types/fixed_string.rs | 274 +++++++++++++++++++++ pve-api-types/src/types/mod.rs | 3 + 5 files changed, 492 insertions(+), 1 deletion(-) create mode 100644 pve-api-types/src/types/fixed_string.rs proxmox-yew-comp: Stefan Hanreich (1): pve: qemu: handle fallback enum variants .../qemu_property/qemu_amd_sev_property.rs | 1 + .../pve/qemu_property/qemu_bios_property.rs | 1 + .../qemu_property/qemu_machine_property.rs | 20 +++++++++++-------- 3 files changed, 14 insertions(+), 8 deletions(-) proxmox-datacenter-manager: Stefan Hanreich (1): tree-wide: handle new unknown enum variants server/src/metric_collection/rrd_task.rs | 4 ++++ ui/src/pve/utils.rs | 1 + ui/src/widget/migrate_window.rs | 6 ++++++ 3 files changed, 11 insertions(+) pve-yew-mobile-gui: Stefan Hanreich (1): tree-wide: handle fallback enum values src/pages/page_resources.rs | 4 +++- src/pages/page_task_status.rs | 7 +++++++ 2 files changed, 10 insertions(+), 1 deletion(-) Summary over all repositories: 13 files changed, 527 insertions(+), 10 deletions(-) -- Generated by git-murpp 0.8.0 _______________________________________________ pdm-devel mailing list pdm-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel