[pdm-devel] [PATCH proxmox/datacenter-manager v2 00/14] initial auto-installer integration

[Lukas Wagner]

Great work in general!

Tried this out on the latest master, seems to work as advertised.

Tested-by: Lukas Wagner <l.wagner at proxmox.com>

I found one small issue while testing, it seems like when you have a
'default' prepared answer which you then edit (keeping 'default'
checked), then one gets the follwowing error:

  'configuration 'test' is already the default answer'

On Fri Dec 5, 2025 at 12:25 PM CET, Christoph Heiss wrote:
> This series adds integration with our automated installer [0] for all our
> products. With this, Proxmox Datacenter Manager can be used for serving
> answer files via HTTP(S) in an automated fashion.
>
> It provides two new panels:
>
> - Automated Installations: List all past and currently ongoing
>   installations.
> - Prepared Answers: Enables users to do the whole CRUD cycle for
>   prepared answers, i.e. create new answers (from scratch or based on
>   existing ones), edit and delete.
>
> Permission-wise, everything is currently scoped on
> /system/auto-installation.
>
> UI
> ==
>
> Happy about feedback regarding the UI, especially the editing dialog! By
> the nature of it, the auto-installer has a lot more options than the
> standard GUI/TUI installer, and it's kind of hard to not fully cramp up
> the UI while still providing all options.
>
> The viewing of the system information and post-installation hook
> notification data is a bit bare-bones. For the first one, maybe
> displaying it as a tree (see also future work) could be a possibility,
> if we don't want to simply display raw JSON documents to the user.
>
> TOML API
> ========
>
> The auto-installer (currently) only supports TOML as input format for
> the answer, so we need to hack around a bit to serve TOML in the API.
> This is done in patch #12, by implementing the api method
> directly. 
>
> Serving TOML from an endpoint under /api2/json/ obviously is rather
> wrong, so I'm definitely open for suggestions. 
> We probably also don't want to implement `/api2/toml/` if I'd have to
> guess (or would that be possible selectively, i.e. just for this one
> endpoint?).
>
> Adding JSON support to proxmox-fetch-answer is on my list, but this
> would still be needed if we want to keep compatibility with older ISOs.
>
> Other future work
> =================
>
> - Switch the installer to use the `proxmox-installer-types` crate too
>   Left this out for now (though I have a mostly-done branch locally
>   already), to ease review.
>
> - Target filter selection by dropdown/tree
>   Based on the system information schema, a list of all possible
>   JSON pointers, or even a tree, could be generated and displayed to the
>   user, in a form consisting of the key, a text input for the value/glob
>   to match and a set of add/remove buttons for each filter.
>
> - Display/saving the installation progress/log. The progress log
>   generated by the auto-installer can be sent to PDM, showing it there
>   similar to tasks.
>   Requires changes to the auto-installer, so this would not be
>   backwards-compatible with older ISOs.

Not sure if worth the effort, but it could also be cool to 'stream' the
logs to PDM, so that one can get a.) a progress bar of the installation
status, and b.) the live output from the installation

>
> - Implement a "wait for answer"-ish system. Core idea here is that the
>   installer waits for PDM to provide in answer by implemented e.g. an
>   retry system. The use case is for to be able to effectively install
>   systems on demand, without the need for preparations.
>   Again requires changes to the auto-installer and wouldn't be
>   backwards-compatible.
>

Some different things that came to mind that could be cool:
  - Have some (basic) integration for the prepare-iso tool, where one could
    automatically download and generate an ISO that is configured with
    the correct URL/fingerprint and also the shared secret that I
    mentioned in one of the patches

 - Ability to add the new node as a remote, either automatically after
   it has been installed or on button-press from the 'Installations'
   screen (automatic could be tricky, since the root password of the
   node is never stored; manual could simply spawn the 'Add Remote'
   dialog prefilled with the values we already know)

 - Add a quick link in the 'Installations' page to open the web
   interface of the installed node.