all lists on lists.proxmox.com
 help / color / mirror / Atom feed
* [pdm-devel] [RFC proxmox{, -yew-comp, -datacenter-manager}/yew-mobile-gui 0/6] Add fallback variant to enum properties in Proxmox VE Rust API types
@ 2025-11-12  9:22 Stefan Hanreich
  2025-11-12  9:22 ` [pdm-devel] [PATCH proxmox 1/3] pve-api-types: add FixedString type Stefan Hanreich
                   ` (5 more replies)
  0 siblings, 6 replies; 12+ messages in thread
From: Stefan Hanreich @ 2025-11-12  9:22 UTC (permalink / raw)
  To: 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.


### Truncating

Unknown enum variants longer than 23 characters can still lead to the same
issues as before. I shortly thought about truncating all longer variants instead
of throwing a hard error, but imo that's a bad idea because:

* deserialize followed by a serialize is no longer an idempotent operation
* accidentally resubmitting truncated values would be *really* bad, whereas
  resubmitting exact values is way less likely to cause trouble.
* we control the length of future enum variants and can take this limit into
  consideration

Nevertheless, I left the implementation for truncating in the impl, since it was
complete and in case it is potentially needed in the future. We could also just
hide it from the public API or remove it altogether, since it is currently
unused and potentially dangerous due to the reasons listed above.


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

proxmox:

Stefan Hanreich (3):
  pve-api-types: add FixedString type
  pve-api-types: generate fallback variant for enums
  pve-api-types: regenerate

 pve-api-types/generator-lib/Schema2Rust.pm |   3 +
 pve-api-types/src/generated/types.rs       | 207 +++++++++++++
 pve-api-types/src/types/fixed_string.rs    | 331 +++++++++++++++++++++
 pve-api-types/src/types/mod.rs             |   3 +
 4 files changed, 544 insertions(+)
 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:
  12 files changed, 579 insertions(+), 9 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


^ permalink raw reply	[flat|nested] 12+ messages in thread
* [pdm-devel] [PATCH proxmox{, -datacenter-manager} 0/8] Integration of IP-VRF and MAC-VRF status to EVPN panel
@ 2025-11-07  8:59 Stefan Hanreich
  2025-11-07  8:59 ` [pdm-devel] [PATCH proxmox 3/3] pve-api-types: regenerate Stefan Hanreich
  0 siblings, 1 reply; 12+ messages in thread
From: Stefan Hanreich @ 2025-11-07  8:59 UTC (permalink / raw)
  To: pdm-devel

This patch series requires the API endpoints introduced in the Proxmox VE patch
series [1] - in particular the zone/ip-vrf and the vnet/mac-vrf endpoints.

It adds a second panel to the EVPN view and makes it a split view similar to the
remote view. It utilizes the endpoints to display status information about
selected zones / vnets.

[1] https://lore.proxmox.com/pve-devel/20251107085553.113655-1-s.hanreich@proxmox.com/T/

proxmox:

Stefan Hanreich (3):
  pve-api-types: add zone / vnet status reporting endpoints
  pve-api-types: generate ip-vrf / mac-vrf endpoints
  pve-api-types: regenerate

 pve-api-types/generate.pl            |   4 +
 pve-api-types/pve-api.json           | 286 ++++++++++++++++++++++++++-
 pve-api-types/src/generated/code.rs  |  25 +++
 pve-api-types/src/generated/types.rs | 104 ++++++++--
 4 files changed, 402 insertions(+), 17 deletions(-)


proxmox-datacenter-manager:

Stefan Hanreich (5):
  server: api: sdn: add ip-vrf endpoint
  server: api: sdn: add mac-vrf endpoint
  ui: sdn: evpn: add zone status panel
  ui: sdn: evpn: add vnet status panel
  sdn: evpn: add detail panel to the evpn panel

 lib/pdm-client/src/lib.rs      |  23 +++
 server/src/api/nodes/mod.rs    |   2 +
 server/src/api/nodes/sdn.rs    | 101 +++++++++++++
 server/src/api/pve/node.rs     |   3 +-
 ui/src/sdn/evpn/evpn_panel.rs  | 129 ++++++++++++++--
 ui/src/sdn/evpn/mod.rs         |  36 +++++
 ui/src/sdn/evpn/remote_tree.rs |  71 ++++++---
 ui/src/sdn/evpn/vnet_status.rs | 253 ++++++++++++++++++++++++++++++++
 ui/src/sdn/evpn/vrf_tree.rs    |  29 +++-
 ui/src/sdn/evpn/zone_status.rs | 261 +++++++++++++++++++++++++++++++++
 10 files changed, 874 insertions(+), 34 deletions(-)
 create mode 100644 server/src/api/nodes/sdn.rs
 create mode 100644 ui/src/sdn/evpn/vnet_status.rs
 create mode 100644 ui/src/sdn/evpn/zone_status.rs


Summary over all repositories:
  14 files changed, 1276 insertions(+), 51 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


^ permalink raw reply	[flat|nested] 12+ messages in thread
* [pdm-devel] [PATCH proxmox{, -datacenter-manager} 0/4] generate Vec's for string-lists
@ 2025-10-21 13:50 Hannes Laimer
  2025-10-21 13:50 ` [pdm-devel] [PATCH proxmox 3/3] pve-api-types: regenerate Hannes Laimer
  0 siblings, 1 reply; 12+ messages in thread
From: Hannes Laimer @ 2025-10-21 13:50 UTC (permalink / raw)
  To: pdm-devel

PVE does accept actual arrays[1] as input to fields with a `-list` format.
This updates the generator so it produces a Vec if it is a parameter,
not for return values.

I did not find endpoint that directly share the same format for
parameters and return value. Update endpoint also include a
`delete`-field and those were the only ones that had really similar
input and output formats. So deduplication in the generate _should_ not be
a problem here.

This required some small changes to pdm. Context for those is in the
commit itself.

[1] pve-common 69d9edcc ("section config: implement array support")


proxmox:

Hannes Laimer (3):
  pve-api-types: schema2rust: generate arrays for types with format
    `-list`
  pve-api-types: add regex for both storage- and bridge-pair
  pve-api-types: regenerate

 pve-api-types/generate.pl                  |  11 +-
 pve-api-types/generator-lib/Schema2Rust.pm |  35 ++-
 pve-api-types/src/generated/code.rs        |   2 +-
 pve-api-types/src/generated/types.rs       | 335 +++++++++++----------
 pve-api-types/src/types/verifiers.rs       |  10 -
 5 files changed, 213 insertions(+), 180 deletions(-)


proxmox-datacenter-manager:

Hannes Laimer (1):
  server: use types indead of string for migration parameters

 server/src/api/pve/lxc.rs  | 133 ++++++++----------------------------
 server/src/api/pve/qemu.rs | 135 ++++++++-----------------------------
 2 files changed, 56 insertions(+), 212 deletions(-)


Summary over all repositories:
  7 files changed, 269 insertions(+), 392 deletions(-)

-- 
Generated by git-murpp 0.8.1


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


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2025-11-12 16:39 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-11-12  9:22 [pdm-devel] [RFC proxmox{, -yew-comp, -datacenter-manager}/yew-mobile-gui 0/6] Add fallback variant to enum properties in Proxmox VE Rust API types Stefan Hanreich
2025-11-12  9:22 ` [pdm-devel] [PATCH proxmox 1/3] pve-api-types: add FixedString type Stefan Hanreich
2025-11-12 10:50   ` Wolfgang Bumiller
2025-11-12 16:39     ` Stefan Hanreich
2025-11-12  9:22 ` [pdm-devel] [PATCH proxmox 2/3] pve-api-types: generate fallback variant for enums Stefan Hanreich
2025-11-12  9:22 ` [pdm-devel] [PATCH proxmox 3/3] pve-api-types: regenerate Stefan Hanreich
2025-11-12  9:22 ` [pdm-devel] [PATCH proxmox-yew-comp 1/1] pve: qemu: handle fallback enum variants Stefan Hanreich
2025-11-12  9:22 ` [pdm-devel] [PATCH proxmox-datacenter-manager 1/1] tree-wide: handle new unknown " Stefan Hanreich
2025-11-12 12:25   ` Lukas Wagner
2025-11-12  9:22 ` [pdm-devel] [PATCH pve-yew-mobile-gui 1/1] tree-wide: handle fallback enum values Stefan Hanreich
  -- strict thread matches above, loose matches on Subject: below --
2025-11-07  8:59 [pdm-devel] [PATCH proxmox{, -datacenter-manager} 0/8] Integration of IP-VRF and MAC-VRF status to EVPN panel Stefan Hanreich
2025-11-07  8:59 ` [pdm-devel] [PATCH proxmox 3/3] pve-api-types: regenerate Stefan Hanreich
2025-10-21 13:50 [pdm-devel] [PATCH proxmox{, -datacenter-manager} 0/4] generate Vec's for string-lists Hannes Laimer
2025-10-21 13:50 ` [pdm-devel] [PATCH proxmox 3/3] pve-api-types: regenerate Hannes Laimer

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal