Am 15.11.24 um 10:34 schrieb Christoph Heiss:
> I see, so probably introduce a `first-boot.ordering` (or similar)
> key, defaulting to "network-pre"?
>
> Should it be an enum then? I.e. only allowing certain values such as
> - network-pre.target
> - network.target
> - network-online.target
> - multi-user.target
Yeah, I would not make it generic, just the two or three most common
orderings, we can then extend it on potential future user demand.
I think before network, post network and finished boot, i.e. multi-user
target seem enough for now.
> Further we could include {local,remote}-fs.target and maybe ceph.target?
Maybe, but wouldn't do that for now, ceph.target on a freshly installed
node seems a bit odd, the fs targets might be sensible, but I would wait
for actual user demand.
> Or just be a freeform text field and let the user decide entirely by
> themselves?
No, that is harder to understand IMO than simple "needed for network
communication itself", "needs working network to run" and "needs fully
booted system to run".
> If we allow configuring that though, we might need to change WantedBy=
> depending on that too.
Changing that might probably make sense.
> Not sure if we could just use multi-user.target as a default target, but
> systemd *should* pull it in and run it in the right ordering too with
> e.g. {Before,Wants}=network-pre.target ?
Isn't the WantedBy is more for defining the target the unit itself will
be part of, or? Adapting that might indeed make sense, but a bit to long
ago that I looked into systemd unit ordering/dependency semantics more
closely.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
