[pbs-devel] [RFC proxmox 1/3] new proxmox-server-config crate

[Thomas Lamprecht]

Am 30/10/2023 um 12:05 schrieb Dominik Csapak:
> On 10/25/23 18:38, Thomas Lamprecht wrote:
>> Would name it "proxmox-rest-server-config" or "proxmox-api-config", and here
>> I'm asking myself (without really trying to answer it myself): why isn't
>> this part of proxmox-rest-server, it's only relevant when used in combination
>> of there, simply to allow use-sites that do not depend on the rest of that
>> crates code?
>>
> 
> you're right that it's currently only used together with the 
> rest-server, but i though it might bite us in the future if we put that 
> together. We might want to have some daemons that does not have a rest
> part in the future?

then adapt to the actual reality that happens in the future? It's not like
this is then set in stone, and especially with rust one can adapt this
relatively easily, or at least without fear of subtle breakage.

> e.g. like we now have a few of them in PVE (pvestatd, qmeventd, spiceproxy)

Yes, which either mostly exists due to the lack of (sane) threading in perl,
or are simple and have no need for worker stuff (like qmeventd, or the syscall
proxy, already written in rust).

> also having more smaller crates does improve compile time for boxes
> with many cores (not really an argument for or against, just a side effect)

This crate is so small, that the static overhead of having it probably even
increases total build time ;-)

But I digress, I do not argue against having small, or even micro crates,
on the contrary they can be great for certain stuff.
And "certain stuff" is doing the heavy lifting there, as there are only some
cases where one can be sure up-front that a micro crate is best. E.g., one
ideal one would have a small scope, and allow one to be almost certain that
the ABI never has to be broken. A config trait crate for our (still a bit messy)
daemons isn't one of those IMO. Most others can only be decided (for sure) in
retrospect, until then the code should live as close to the actual use case
as possible (i.e., a micro crate can be fine, having it in the crate that uses
it can be fine, but not putting it in-between in some monster helper crate
like proxmox-sys please!).

Here it could be OK'ish, but I'd favor having this in rest-server until there's
an actual use case to reason about.
 >> Also, mostly important for  the other two crates: did you check the history
>> of the files you mode? If there's anything relevant, I'd favor isolating that
>> and then merging it in, like I did when splitting out rest-server, but it can
>> sometimes be a bit of a PITA, so  can be decided case-by-case for those new
>> crates..
>>
> 
> i'll look into it. I did not spend much time on such things for the RFC.
> just wanted to see how others feel about the general approach

If it's messy, or hardly worth it, then specifying the previous location
(including some verison, or even commit rev) would already make it lots
easier to find, if really needed.


>>> +    name: String,
>>> +    base_dir: PathBuf,
>>> +    user: User,
>>> +    privileged_user: OnceLock<User>,
>>> +
>>> +    task_dir: OnceLock<PathBuf>,
>>
>> not sure if this should be an option, e.g., for simple CRUD
>> API daemons there might not be any worker tasks at all.
>>
> 
> that's one reason i used OnceLock, since it's only created when either
> one sets it manually, or access it the first time
> 
> but Option would work too ofc if that's preferred

no hard preference, but Option feels more explicit for a, well optional,
use-case – but if we keep this code in proxmox-rest-server for now it
wouldn't matter anyway.