Re: [PATCH v2 3/4] build: move COLO under CONFIG_REPLICATION

[Vladimir Sementsov-Ogievskiy]

On 21.04.23 06:02, Zhang, Chen wrote:
> > -----Original Message-----
> > From: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
> > Sent: Thursday, April 20, 2023 6:53 AM
> > To: qemu-devel@nongnu.org
> > Cc: qemu-block@nongnu.org; michael.roth@amd.com; armbru@redhat.com;
> > eblake@redhat.com; jasowang@redhat.com; quintela@redhat.com; Zhang,
> > Hailiang <zhanghailiang@xfusion.com>; philmd@linaro.org;
> > thuth@redhat.com; berrange@redhat.com; marcandre.lureau@redhat.com;
> > pbonzini@redhat.com; dave@treblig.org; hreitz@redhat.com;
> > kwolf@redhat.com; Zhang, Chen <chen.zhang@intel.com>;
> > lizhijian@fujitsu.com; Vladimir Sementsov-Ogievskiy <vsementsov@yandex-
> > team.ru>
> > Subject: [PATCH v2 3/4] build: move COLO under CONFIG_REPLICATION
> >
> > We don't allow to use x-colo capability when replication is not configured. So,
> > no reason to build COLO when replication is disabled, it's unusable in this
> > case.
>
> Yes, you are right for current status. Because COLO best practices is 
> replication + colo live migration + colo proxy.
> But doesn't mean it has to be done in all scenarios as I explanation in V1.
> The better way is allow to use x-colo capability firstly, and separate this 
> patch
> with two config options: --disable-replication  and --disable-x-colo.

But what for? We for sure don't have such scenarios now (COLO without 
replication), as it's not allowed by far 7e934f5b27eee1b0d7 (by you and David).

If you think we need such scenario, I think it should be a separate series 
which reverts 7e934f5b27eee1b0d7 and adds corresponding test and probably 
documentation.


--
Best regards,
Vladimir