From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 Cc: Proxmox VE development discussion References: <20240328135028.504520-1-a.lauterer@proxmox.com> From: Aaron Lauterer In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > > in any case.