Re: [PATCH datacenter-manager 06/20] pdm-config: subscriptions: rename trait methods to read/write/lock

["Lukas Wagner" <l.wagner@proxmox.com>]

On Fri Aug 21, 2026 at 4:00 PM CEST, Robert Obkircher wrote:
>> PdmApplication bundles the client factory, remote config, subscription
>> key config, and product config behind a single cloneable handle. This
>> replaces the growing set of independent global statics with one object
>> that can be assembled differently for production, the fake-remote
>> feature, and integration tests.
>
> Bundling them is convenient, but the components could additionally be
> registered individually, to allow for application independent methods.

Yeah, I'm also not 100% sure about the best granularity here. For
application-independent methods defined in shared crates it could also
make sense to use specific context types that can be injected, e.g. if
there is proxmox-foo that defines API handlers, there could be

struct FooContext {
    product_config: ProductConfig, // that would be a clone of the one in PdmApplication

    // ... and other stuff needed for proxmox-foo
}

and then the API handlers in proxmox-foo would take State<FooContext> as
a state-arg.

This might be preferable, since most likely the shared crate is going
to need *some* kind of app-specific context anyway (for example, see the
app-specific context in proxmox-notify [1])


[1] https://git.proxmox.com/?p=proxmox.git;a=blob;f=proxmox-notify/src/context/pve.rs;h=3d9ff92e9bf4688ce199ba68e72706ae3d1d6ae1;hb=HEAD#l32

>
> e.g. State<ProductConfig> could work in PBS as well. That might be a
> bad example though, becasue api_user and priv_user are used all over
> the place and should maybe remain static [1].
>
> I wonder if conditionally compiling to static variables for release
> builds and tokio::task_local in tests would work there.
>