All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Lukas Straub <lukasstraub2@web.de>
Cc: "Peter Xu" <peterx@redhat.com>,
	qemu-devel@nongnu.org, "Juraj Marcin" <jmarcin@redhat.com>,
	"Fabiano Rosas" <farosas@suse.de>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	"Juan Quintela" <quintela@trasno.org>,
	"Dr. David Alan Gilbert" <dave@treblig.org>,
	"Zhang Chen" <zhangckid@gmail.com>,
	zhanghailiang@xfusion.com, "Li Zhijian" <lizhijian@fujitsu.com>,
	"Jason Wang" <jasowang@redhat.com>
Subject: Re: [PATCH 1/3] migration/colo: Deprecate COLO migration framework
Date: Fri, 16 Jan 2026 07:26:31 +0100	[thread overview]
Message-ID: <87ecnqt6nc.fsf@pond.sub.org> (raw)
In-Reply-To: <20260115224929.616aab85@penguin> (Lukas Straub's message of "Thu, 15 Jan 2026 22:49:29 +0100")

Lukas Straub <lukasstraub2@web.de> writes:

> On Wed, 14 Jan 2026 15:11:55 -0500
> Peter Xu <peterx@redhat.com> wrote:
>
>> On Wed, Jan 14, 2026 at 02:56:57PM -0500, Peter Xu wrote:
>> > COLO was broken for QEMU release 10.0/10.1 without anyone noticed.  One
>> > reason might be that we don't have an unit test for COLO (which we
>> > explicitly require now for any new migration feature).  The other reason
>> > should be that there are just no more active COLO users, at least based on
>> > the latest development of QEMU.
>> > 
>> > I don't remember seeing anything really active in the past few years in
>> > COLO development.
>> > 
>> > Meanwhile, COLO migration framework maintainer (Hailiang Zhang)'s last
>> > email to qemu-devel is in Dec 2021 where the patch proposed an email
>> > change (<20211214075424.6920-1-zhanghailiang@xfusion.com>).
>> > 
>> > We've discussed this for a while, see latest discussions here (our thoughts
>> > of deprecating COLO framework might be earlier than that, but still):
>> > 
>> > https://lore.kernel.org/r/aQu6bDAA7hnIPg-y@x1.local/
>> > https://lore.kernel.org/r/20251230-colo_unit_test_multifd-v1-0-f9734bc74c71@web.de
>> > 
>> > Let's make it partly official and put COLO into deprecation list.  If
>> > anyone cares about COLO and is deploying it, please send an email to
>> > qemu-devel to discuss.
>> > 
>> > Otherwise, let's try to save some energy for either maintainers or
>> > developers who is looking after QEMU. Let's save the work if we don't even
>> > know what the work is for.
>> > 
>> > Cc: Lukáš Doktor <ldoktor@redhat.com>  
>> 
>> My apologize, I copied the wrong email.
>> 
>> Cc: Lukas Straub <lukasstraub2@web.de>
>
> Nack.
>
> This code has users, as explained in my other email:
> https://lore.kernel.org/qemu-devel/20260115224516.7f0309ba@penguin/T/#mc99839451d6841366619c4ec0d5af5264e2f6464

Code being useful is not enough.  We must have people to maintain it
adequately.  This has not been the case for COLO in years.

Deprecating a feature with intent to remove it is not a death sentence.
It's a *suspended* death sentence: if somebody steps up to maintain it,
we can revert the deprecation, or extend the grace period to give them a
chance.

I think we should deprecate COLO now to send a clear distress signal.
The deprecation notice should explain it doesn't work, and will be
removed unless people step up to fix it and to maintain it.  This will
ensure progress one way or the other.  Doing nothing now virtually
ensures we'll have the same discussion again later.

"Broken for two releases without anyone noticing" and "maintainer absent
for more than four years" doesn't exacltly inspire hope, though.  We
should seriously consider removing it right away.

Lukas, can you give us hope?

[...]



  parent reply	other threads:[~2026-01-16  6:27 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-14 19:56 [PATCH 0/3] migration: deprecations and removals for 11.0 Peter Xu
2026-01-14 19:56 ` [PATCH 1/3] migration/colo: Deprecate COLO migration framework Peter Xu
2026-01-14 20:11   ` Peter Xu
2026-01-15 21:49     ` Lukas Straub
2026-01-15 22:39       ` Peter Xu
2026-01-15 22:59         ` Dr. David Alan Gilbert
2026-01-15 23:38           ` Peter Xu
2026-01-16  0:37             ` Dr. David Alan Gilbert
2026-01-16  8:16               ` Zhang Chen
2026-01-16  7:47             ` Zhang Chen
2026-01-17 19:49             ` Lukas Straub
2026-01-17 20:15               ` Lukas Straub
2026-01-19 22:33               ` Peter Xu
2026-01-20 11:48                 ` Lukas Straub
2026-01-20 15:58                   ` Peter Xu
2026-01-20 19:04                     ` Dr. David Alan Gilbert
2026-01-20 19:50                       ` Peter Xu
2026-01-21  1:25                         ` Dr. David Alan Gilbert
2026-01-21 17:03                           ` Peter Xu
2026-01-21 17:31                             ` Dr. David Alan Gilbert
2026-01-21 20:22                               ` Peter Xu
2026-01-21 21:31                                 ` Dr. David Alan Gilbert
2026-01-21 22:22                                   ` Peter Xu
2026-01-16  7:05           ` Zhang Chen
2026-01-16  9:46           ` Daniel P. Berrangé
2026-01-16 13:56             ` Peter Xu
2026-01-16  6:26       ` Markus Armbruster [this message]
2026-01-16  8:22         ` Zhang Chen
2026-01-16  9:41           ` Markus Armbruster
2026-01-16 14:08             ` Peter Xu
2026-01-16 15:33               ` Markus Armbruster
2026-01-14 21:13   ` Dr. David Alan Gilbert
2026-01-15  5:56   ` Markus Armbruster
2026-01-15 18:53     ` Peter Xu
2026-01-14 19:56 ` [PATCH 2/3] migration: Remove zero-blocks capability Peter Xu
2026-01-15  6:00   ` Markus Armbruster
2026-01-15 18:53     ` Peter Xu
2026-01-14 19:56 ` [PATCH 3/3] migration: Remove fd: support on files Peter Xu
2026-01-14 22:10   ` Peter Xu
2026-01-15 12:15   ` Prasad Pandit
2026-01-15 17:39     ` Peter Xu
2026-01-15  6:11 ` [PATCH 0/3] migration: deprecations and removals for 11.0 Markus Armbruster
2026-01-15 18:58   ` Peter Xu
2026-01-15 14:37 ` Fabiano Rosas

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=87ecnqt6nc.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dave@treblig.org \
    --cc=farosas@suse.de \
    --cc=jasowang@redhat.com \
    --cc=jmarcin@redhat.com \
    --cc=lizhijian@fujitsu.com \
    --cc=lukasstraub2@web.de \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@trasno.org \
    --cc=zhangckid@gmail.com \
    --cc=zhanghailiang@xfusion.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.