Re: [pve-devel] [RFC installer 2/6] add proxmox-auto-installer

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

Am 21/09/2023 um 13:16 schrieb Christoph Heiss:
> 
> Some general notes:
> 
> - The overall approach seems fine too me. Did some cursory testing too,
>   worked fine - although I did not really test out the
>   filtering/matching much.
> 
> - Probably just due to it being still a bit early, but all these
>   `.unwrap()/.expect()` should be replaced with proper error handling in
>   the end.
> 
> - Continuing on the thought of error handling:
>   We should come up with some way to properly report and (persistently)
>   log errors, such that an user can see them. It's really not helpful if
>   the machine is just boot-looping without any indication what went
>   wrong. Any `.expect()`/`.unwrap()` will just panic the auto-installer,
>   which will ultimately result in a reboot.
> 
>   Especially in this case, where everything runs headless, it's IMO
>   important to have /some/ way to know what went wrong.
> 
>   Sending simple JSON-formatted logs to an HTTP endpoint or even using
>   the rsyslog protocol come to mind and would be a good solution for
>   this, I think.
>   Or, if the answer file is read from an (USB drive) partition, write
>   the log there?

I think this should be added to the config as option and default to
"stop-and-wait-for-human-intervention", i.e., show error in a prompt
and wait.

We can then add other reporting mechanisms in the future, possibly
dependent on where the config is pulled from.

> 
>   At the very least, I would log everything to a tmpfile, such that an
>   administrator can e.g. upload that file somewhere using a post-install
>   command.
> 
>   Maybe even /disable/ auto-reboot in case of an error, so that
>   administrators can investigate the machine directly?
> 
> - For the most part I did a rather in-depth review, just as things
>   caught my eye. Still trimmed down things as much as possible.
> 
> On Tue, Sep 05, 2023 at 03:28:28PM +0200, Aaron Lauterer wrote:
>> [..]
>>
>> It supports basic globbing/wildcard is supported at the beginning and
>> end of the search string. The matching is implemented by us as it isn't
>> that difficult and we can avoid additional crates.
> If we ever want more extensive matching in the future, we could use the
> `glob` crate, which provides a `Pattern` struct for using it directly.
> It's actively maintained and does not have any non-dev dependencies, so
> from my side it would be fine.

yes, IIRC, we mentioned that crate too when we discussed the general
strategy and matching in-person some months ago; would be fine for me
too.


> [..]
>
> Further, a way to run commands in the finished installation chroot could
> be pretty useful too, e.g. to create some files in /etc comes to mind.

I would like to avoid having such things from the start, let's keep
it simple for now and collect feedback when this is then released.
As then, we can decide which mechanism make sense as native feature
and if we really want such a general hook that can allow users to
break lots off stuff and assumptions and still say "well I used the
official installer", i.e., cause support overhead.