[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC 0/6] Migration deprecated parts
From: |
Jiri Denemark |
Subject: |
Re: [RFC 0/6] Migration deprecated parts |
Date: |
Tue, 13 Jun 2023 09:48:03 +0200 |
User-agent: |
Mutt/2.2.10 (2023-03-25) |
On Mon, Jun 12, 2023 at 21:33:38 +0200, Juan Quintela wrote:
> Hi this series describe the migration parts that have to be deprecated.
>
> - It is an rfc because I doubt that I did the deprecation process right.
> Hello Markus O:-)
>
> - skipped field: It is older than me, I have never know what it stands
> for. As far as I know it has always been zero.
Libvirt doesn't use this.
> - inc/blk migrate command options. They are only used by block
> migration (that I deprecate on the following patch). And they are really
> bad.
> grep must_remove_block_options.
>
> - block migration. block jobs, whatever they are called this week are
> way more flexible. Current code works, but we broke it here and
> there, and really nobody has stand up to maintain it. It is quite
> contained and can be left there. Is anyone really using it?
We prefer nbd for storage migration if it is available.
> - old compression method. It don't work. See last try from Lukas to
> make a test that works reliabely. I failed with the same task years
> ago. It is really slow, and if compression is good for you, multifd
> + zlib is going to perform/compress way more.
We do support these methods, but only enable them if a user explicitly
requests so. In other words, the user will just get an error once these
methods are removed, which is fine.
> - -incoming <uri>
>
> if you need to set parameters (multifd cames to mind, and preempt has
> the same problem), you really needs to use defer. So what should we do
> here?
>
> This part is not urget, because management apps have a working
> option that are already using "defer", and the code simplifacation
> if we remove it is not so big. So we can leave it until 9.0 or
> whatever we think fit.
Right, libvirt already uses -incoming defer if supported.
In other words, no objection to removing anything on this list and no
additional work is needed on libvirt side.
Jirka
- Re: [RFC 4/6] migration: Deprecate -incoming <uri>, (continued)