[pve-devel] applied: [PATCH installer 0/5] allow both snake- and kebab-cased property names in the answer file

[Thomas Lamprecht]

Am 17.02.25 um 13:17 schrieb Daniel Kral:
> This is a followup to a previous discussion at [0].
> 
> Small patch series which allows both snake- and kebab-cased property
> names in the configuration file for the auto installer, i.e. answer
> files. This allows to introduce a migration from snake_cased towards
> kebab-cased property names in the answer file to be consistent with
> other configuration files, which prefer kebab-case too.
> 
> The only property key that was not changed in casing was the filter
> match rules for network and block devices as those are not in our
> control, but matches the udevadm output's JSON property keys (e.g.
> "filter.ID_MODEL").
> 
> The last patch introduces a deprecation warning that is output to the
> user when verifying answer files and preparing auto installer ISOs with
> the assistant to be applied for a major version bump, i.e. PVE
> 9.0/Trixie-based releases as suggested by @Thomas at [0].
> 
> [0] https://lore.proxmox.com/pve-devel/0dec173a-da75-4d70-ac07-e1133c136081@proxmox.com/
> 
> Daniel Kral (5):
>   auto-installer: factor out field rename casing for network config mode
>   auto-installer: first-boot: allow snake- and kebabcased property names
>   auto-installer: allow snake- and kebabcased property names in answer
>     files
>   auto-installer: add redundant kebab-case renames to config structures
>   assistant: add deprecation notice for snakecased parameters
> 
>  proxmox-auto-install-assistant/src/main.rs | 24 ++++++++++++++++
>  proxmox-auto-installer/src/answer.rs       | 33 +++++++++++++---------
>  2 files changed, 44 insertions(+), 13 deletions(-)
> 


applied series, thanks!

But shortly discussed off-list I squashed the commits into a single one.
As while I get how you separate it, and I'm generally in favor of not
squashing every that looks similar into the same commit, this here is
basically a single semantic change where one has a better git log "reading
flow" if one sees the full change all in a single commit.

Just for the sake of completeness: If in doubt, I'd almost always favor
having the commits split over squashed, as squashing is normally a very
quick operation; so it was IMO definitively also an OK call to send this
series the way you did.