From: Fiona Ebner <f.ebner@proxmox.com>
To: Erik Fastermann <e.fastermann@proxmox.com>, pve-devel@lists.proxmox.com
Subject: Re: [RFC qemu-server 2/4] remote migrate: collect preconditions as structured findings
Date: Wed, 5 Aug 2026 11:26:55 +0200 [thread overview]
Message-ID: <315b27c5-9fd7-4cd8-991e-597e8990ee9a@proxmox.com> (raw)
In-Reply-To: <63311ffa-f824-4322-9360-a456e4e51401@proxmox.com>
Am 31.07.26 um 3:42 PM schrieb Erik Fastermann:
>>> User-visible effect is minimal: successful migrations are unchanged.
>>> Some precondition error messages are reworded and the "Establishing
>>> API connection" info line is no longer printed.
>>
>> Do we gain anything from not printing it? Such changes can also be nicer
>> in separate patches to ease reviewability and discussion.
>>
>
> I thought printing the info line would be noise in the precondition
> endpoint, which I can put in the commit message, in a separate patch.
Okay, I see. I'm not sure it's too much noise, but I'm fine either way.
Putting the rationale in the commit message in the same patch is enough.
>
> [snip]
>>> + my $findings = [];
>>> + my $plan = validate_remote_migrate_preconditions($param,
>>> $findings);
>>
>> Style nit: why pass in $findings like this? You can just return multiple
>> values instead. I'd prefer a name like $migration_info rather than $plan.
>>
>
> I didn't want to return the findings array on every possible exit point
> of the function, so I thought this would be nicer. I could add an extra
> wrapper function which does this though, so I will try that.
Okay, I see. I feel like an extra wrapper is not worth it. It's fine to
keep it as-is IMHO (I'd still like the $plan -> $migration_info rename).
next prev parent reply other threads:[~2026-08-05 9:27 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-21 11:58 [RFC qemu-server 0/4] remote migrate: extract preconditions and add check endpoint Erik Fastermann
2026-07-21 11:58 ` [RFC qemu-server 1/4] remote migrate: drop ineffective fingerprint auto-detection Erik Fastermann
2026-07-29 9:56 ` Fiona Ebner
2026-07-29 9:59 ` Fiona Ebner
2026-07-29 10:02 ` Fiona Ebner
2026-07-29 10:07 ` Fabian Grünbichler
2026-07-29 10:17 ` Fiona Ebner
2026-07-21 11:58 ` [RFC qemu-server 2/4] remote migrate: collect preconditions as structured findings Erik Fastermann
2026-07-29 9:56 ` Fiona Ebner
2026-07-31 13:42 ` Erik Fastermann
2026-08-05 9:26 ` Fiona Ebner [this message]
2026-07-21 11:58 ` [RFC qemu-server 3/4] qm: remote-migrate: call API endpoint directly Erik Fastermann
2026-07-21 11:58 ` [RFC qemu-server 4/4] remote migrate: add precondition check endpoint Erik Fastermann
2026-07-29 9:56 ` Fiona Ebner
2026-07-31 13:43 ` Erik Fastermann
2026-08-05 9:26 ` Fiona Ebner
2026-07-29 9:56 ` [RFC qemu-server 0/4] remote migrate: extract preconditions and add " Fiona Ebner
2026-07-31 13:42 ` Erik Fastermann
2026-07-31 14:44 ` Daniel Kral
2026-08-05 9:26 ` Fiona Ebner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=315b27c5-9fd7-4cd8-991e-597e8990ee9a@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=e.fastermann@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox