[pve-devel] applied: [PATCH installer v4 00/12] fix #5536: implement post-(auto-)installation notification mechanism

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

Am 11.11.24 um 14:14 schrieb Christoph Heiss:
> This implements a mechanism for post-installation "notifications" via a
> POST request [0] when using the auto-installer.
> 
> It's implemented as a separate, small utility to facilitate separation
> of concerns and make the information gathering easier by having it
> isolated in one place.
> 
> Patches #1 through #5 are simply clean-ups, refactors, etc. that were
> done along the way and can be applied independently.
> 
> Most interesting here will be patch #16, which adds the actual
> implementation of the post-hook. (Bind-)mounting the installed host
> system is done using the existing `proxmox-chroot` utility, and the HTTP
> POST functionality can fortunately be re-used 1:1 from
> `proxmox-fetch-answer`.
> 
> I've also included an example of how the JSON body (pretty-printed and
> reduced some things for readability) of such a post-installation request
> would look like below, for reference. 
> Where applicable (and sensible), I have tried to align the format as
> much as possible with 1) the format as used in the `fetch-answer` POST
> request and 2) PVE's /nodes/<host>/status API endpoint.
> 
> Feedback on the post-hook information schema is of course also very much
> appreciated!

What about adding an X.Y format version? So that we can expand this nicely or
even rework completely. Here the semantic meaning of the two tuples would
be

X: major version, increased if existing keys vanish or get renamed or
   restructured, i.e. a breaking change.

Y: minor version, increased if new information gets added.

A patch level does not make much sense here IMO, so I left that out.
This way consumers could decide if they can cope with the current format
version and e.g. take different actions or what not.

One naturally can use the product version for deriving the format version,
but in the long run that needs more client side handling and mapping than
a separate format version.

> 
> It should be noted that some information like DMI is generally very
> depended on the motherboard/firmware, on what information is actually
> available and filled-in. So the contents are expected to vary wildly
> between machines and may also be empty, as in the example below from a
> VM.

Can we also dump the schema so that this can be added to the docs, or
at least (linked to) in the wiki of the automated installer?

Also, I figure you already planned to document this in the wiki for the
next ISO release? Just asking to be sure it won't be overlooked.

> 
> Diffstat
> ========
> 
> Christoph Heiss (12):
>   debian: strip unused library dependencies
>   fetch-answer: move http-related code to gated module in
>     installer-common
>   tree-wide: convert some more crates to use workspace dependencies
>   auto-install-assistant: replace `PathBuf` parameters with
>     `AsRef<Path>`

^- this one would have done well with some short commit message body,
even if obvious it will never hurt to state the intention of the commit.

>   auto-installer: tests: simplify empty disks check
>   auto-installer: tests: replace `PathBuf` parameters with `AsRef<Path>`

^- same here w.r.t. the lack of a short commit message body

>   auto-installer: move `SystemDMI` struct to common crate
>   auto-installer: answer: factor out answer file reading into function
>   auto-installer: udevinfo: introduce type alias for udev properties
>   fix #5536: auto-installer: answer: add `posthook` section
>   fix #5536: post-hook: add utility for sending notifications after
>     auto-install

^- above two might have been better off squashed, but I can get how you
wanted to separate them, so I kept them as is.

>   unconfigured.sh: run proxmox-post-hook after successful auto-install



applied series, thanks!


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