The reason in MIGRATION event can be used, when there is some helpful
message, that can be added to improve debugging\understanding of the
reason of migration status changing.
I propose the next usage - when qemu sends (MIGRATION status=failed)
event, the error message describing the problem can be sent in that
event too. This is more comfortable way to understand the problem
comparing to reading qemu logs, especially in some cases, where qemu are
launched and monitored through various automation processes (examples:
cloud environments, some 'integration' tests of the qemu, etc).
Probably, there are some other cases when the accompanying message can
be useful, not only in failed migrations, but now I don't know that cases.
If we have common understanding with that, I will improve the doc
comment and the commit message of the first path too in the next version
of the series.
On 2/19/24 11:35, Markus Armbruster wrote:
Roman Khapov <rkha...@yandex-team.ru> writes:
To be clear: you meant that the description of the event must be extended,
similar to its description on the commit message? Or you don't see its proper
usage at all?
The commit message doesn't really tell me either why and how anybody
would use @reason. Once we have a common understanding there, improving
the doc comment should be straightforward.
--
Best regards,
Roman Khapov
