From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <a.lauterer@proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits))
(No client certificate requested)
by lists.proxmox.com (Postfix) with ESMTPS id 9255590723
for <pve-devel@lists.proxmox.com>; Tue, 2 Apr 2024 16:55:13 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id 72DDF7EE5
for <pve-devel@lists.proxmox.com>; Tue, 2 Apr 2024 16:55:13 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
[94.136.29.106])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits))
(No client certificate requested)
by firstgate.proxmox.com (Proxmox) with ESMTPS
for <pve-devel@lists.proxmox.com>; Tue, 2 Apr 2024 16:55:12 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 9ACAF44776
for <pve-devel@lists.proxmox.com>; Tue, 2 Apr 2024 16:55:12 +0200 (CEST)
Message-ID: <76606273-15d8-46c8-836a-bb23276bf2ca@proxmox.com>
Date: Tue, 2 Apr 2024 16:55:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Christoph Heiss <c.heiss@proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
References: <20240328135028.504520-1-a.lauterer@proxmox.com>
<mrkk4loy3v6zdiabd2k336dh7uif7i6gjs3tkzocmfa2xbqc5b@66mbdcgkpzdb>
From: Aaron Lauterer <a.lauterer@proxmox.com>
In-Reply-To: <mrkk4loy3v6zdiabd2k336dh7uif7i6gjs3tkzocmfa2xbqc5b@66mbdcgkpzdb>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-SPAM-LEVEL: Spam detection results: 0
AWL -0.058 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DMARC_MISSING 0.1 Missing DMARC policy
KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record
SPF_PASS -0.001 SPF: sender matches SPF record
Subject: Re: [pve-devel] [PATCH v3 00/30] add automated/unattended
installation
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2024 14:55:13 -0000
thanks for looking into this
On 2024-04-02 16:43, Christoph Heiss wrote:
> Rebuild an (PVE) ISO to contain the new auto-installer with an
> appropriate GRUB entry setting `proxauto` on the kernel commandline.
>
> What I've tried:
>
> - Using a few different values for `global` options
> - Install on ext4, xfs, Btrfs RAID1 and ZFS RAID1
> (with different values in multiple runs)
> - Using DHCP and static IP
> - Fetching answer from a HTTP source, getting the URL from DHCP
> - Trying out the `proxmox-autoinst-helper` tool for assembling udev
> rules and validating files.
> - Using the `post_command` to create some files in the newly installed
> system.
>
> I didn't play around all that extensively the udev filters.
>
> Some notes:
>
> - When using ext4 or xfs as filesystem, `disk_list` happily takes
> multiple disks (but really only installs on the first disk, of
> course). Should probably be another sanity check there.
Good idea. I'll add a check for this.
>
> - As for the `proxmox-autoinst-helper answer` command, might `validate`
> or `validate-answer` be a better name?
> `answer` alone seems a bit confusing at first, as if e.g. the tool
> would give me an answer file or similar.
Hmm, yeah. I see your point and will change that.
>
> - `{pre,post}_command` in the answer file should be spelled plural, as
> it is an array of commands after all.
good point
>
> - While trying out different configurations, I wondered if for the
> network something like this would be better for static IPs:
>
> [network.manual]
> cidr = ".."
> dns = ".."
> [..]
>
> .. keeping the `network.use_dhcp` option as before. Would simplify
> some checks now and provide good future-proofing for any new options
> that might get added.
>
> Thereby basically modelling
> `proxmox_auto_installer::answer::NetworkSettings` enum nearly 1:1 to
> the TOML config.
okay, so that in the DHPC case, it could be
[network]
use_dhcp = true
and in the manual case, either
[network]
manual.cidr = "…"
manual.dns = "…"
and so forth, or, to keep it simpler, like your example with
[network.manual] defining the overall manual key.
This will make it slightly more elaborate to document, as we need to dig
deeper into how TOML works and that there are multiple ways to define
the same hierarchy. But it could be worth it to keep the definition cleaner.
Some more feedback in that regard might be useful, especially since
changing the format later on will be, as you described it, a PITA :)
>
> Nitpicking at this point, I know, but changing the answer format
> afterwards would be a quite a PITA :^)
>
> Overall very nice! and
>
> Tested-by: Christoph Heiss <c.heiss@proxmox.com>
>
> in any case.