qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: qemu-devel@nongnu.org, "Markus Armbruster" <armbru@redhat.com>,
	"Leonardo Bras" <leobras@redhat.com>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	qemu-block@nongnu.org, "Stefan Hajnoczi" <stefanha@redhat.com>,
	"Eric Blake" <eblake@redhat.com>, "Fam Zheng" <fam@euphon.net>,
	"Thomas Huth" <thuth@redhat.com>,
	libvir-list@redhat.com, "Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [RFC 4/6] migration: Deprecate -incoming <uri>
Date: Mon, 12 Jun 2023 22:51:08 +0200	[thread overview]
Message-ID: <875y7sflqb.fsf@secure.mitica> (raw)
In-Reply-To: <ZId0+HYF/ETLVri3@x1n> (Peter Xu's message of "Mon, 12 Jun 2023 15:41:44 -0400")

Peter Xu <peterx@redhat.com> wrote:
> On Mon, Jun 12, 2023 at 09:33:42PM +0200, Juan Quintela wrote:
>> Only "defer" is recommended.  After setting all migation parameters,
>> start incoming migration with "migrate-incoming uri" command.
>> 
>> Signed-off-by: Juan Quintela <quintela@redhat.com>
>> ---
>>  docs/about/deprecated.rst | 7 +++++++
>>  softmmu/vl.c              | 2 ++
>>  2 files changed, 9 insertions(+)
>> 
>> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
>> index 47e98dc95e..518672722d 100644
>> --- a/docs/about/deprecated.rst
>> +++ b/docs/about/deprecated.rst
>> @@ -447,3 +447,10 @@ The new way to modify migration is using migration parameters.
>>  ``blk`` functionality can be acchieved using
>>  ``migrate_set_parameter block-incremental true``.
>>  
>> +``-incoming uri`` (since 8.1)
>> +'''''''''''''''''''''''''''''
>> +
>> +Everything except ``-incoming defer`` are deprecated.  This allows to
>> +setup parameters before launching the proper migration with
>> +``migrate-incoming uri``.
>> +
>> diff --git a/softmmu/vl.c b/softmmu/vl.c
>> index b0b96f67fa..7fe865ab59 100644
>> --- a/softmmu/vl.c
>> +++ b/softmmu/vl.c
>> @@ -2651,6 +2651,8 @@ void qmp_x_exit_preconfig(Error **errp)
>>      if (incoming) {
>>          Error *local_err = NULL;
>>          if (strcmp(incoming, "defer") != 0) {
>> +            warn_report("-incoming %s is deprecated, use -incoming defer and "
>> +                        " set the uri with migrate-incoming.", incoming);
>
> I still use uri for all my scripts, alongside with "-global migration.xxx"
> and it works.

You know what you are doing (TM).
And remember that we don't support -gobal migration.x-foo.
Yes, I know, we should drop the "x-" prefixes.

> Shall we just leave it there?  Or is deprecating it helps us in any form?

See the patches two weeks ago when people complained that lisen(.., num)
was too low.  And there are other parameters that work the same way
(that I convenientely had forgotten).  So the easiest way to get things
right is to use "defer" always.  Using -incoming "uri" should only be
for people that "know what they are doing", so we had to ways to do it:
- review all migration options and see which ones work without defer
  and document it
- deprecate everything that is not defer.

Anything else is not going to be very user unfriendly.
What do you think.

Later, Juan.

PD.  This series are RFC for multiple reasons O:-)



  reply	other threads:[~2023-06-12 20:52 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-12 19:33 [RFC 0/6] Migration deprecated parts Juan Quintela
2023-06-12 19:33 ` [RFC 1/6] migration: skipped field is really obsolete Juan Quintela
2023-06-20 12:01   ` Daniel P. Berrangé
2023-06-22 17:49     ` Juan Quintela
2023-06-12 19:33 ` [RFC 2/6] migration: migrate 'inc' command option is deprecated Juan Quintela
2023-06-20 12:05   ` Daniel P. Berrangé
2023-06-22 18:11     ` Juan Quintela
2023-06-12 19:33 ` [RFC 3/6] migration: migrate 'blk' " Juan Quintela
2023-06-20 12:06   ` Daniel P. Berrangé
2023-06-22 18:12     ` Juan Quintela
2023-06-12 19:33 ` [RFC 4/6] migration: Deprecate -incoming <uri> Juan Quintela
2023-06-12 19:41   ` Peter Xu
2023-06-12 20:51     ` Juan Quintela [this message]
2023-06-12 21:19       ` Peter Xu
2023-06-20 12:13         ` Daniel P. Berrangé
2023-06-22 19:34         ` Juan Quintela
2023-06-20 12:10       ` Daniel P. Berrangé
2023-06-20 14:45         ` Peter Xu
2023-06-22  8:28       ` Paolo Bonzini
2023-06-22  8:52         ` Juan Quintela
2023-06-22  9:22           ` Thomas Huth
2023-06-22 15:25             ` Peter Xu
2023-06-22 19:37               ` Juan Quintela
2023-06-22  9:45           ` Paolo Bonzini
2023-06-22 10:01             ` Juan Quintela
2023-06-22 15:24               ` Peter Xu
2023-06-22 16:03                 ` Paolo Bonzini
2023-06-22  9:59           ` Daniel P. Berrangé
2023-06-22 15:54             ` Peter Xu
2023-06-22 16:33               ` Daniel P. Berrangé
2023-06-22 19:20                 ` Peter Xu
2023-06-23  7:17                   ` Daniel P. Berrangé
2023-06-23 14:34                     ` Peter Xu
2023-06-23  8:23               ` Daniel P. Berrangé
2023-06-23 14:51                 ` Peter Xu
2023-06-23 15:03                   ` Daniel P. Berrangé
2023-06-21  7:08   ` Thomas Huth
2023-06-22  2:22     ` Juan Quintela
2023-06-22  8:30     ` Paolo Bonzini
2023-06-22 18:12   ` Juan Quintela
2023-06-12 19:33 ` [RFC 5/6] migration: Deprecate block migration Juan Quintela
2023-06-21 11:45   ` Stefan Hajnoczi
2023-06-22 18:17     ` Juan Quintela
2023-06-12 19:33 ` [RFC 6/6] migration: Deprecated old compression method Juan Quintela
2023-06-21  7:14   ` Thomas Huth
2023-06-22 19:21     ` Juan Quintela
2023-06-21 10:31   ` Daniel P. Berrangé
2023-06-22 19:32     ` Juan Quintela
2023-06-13  7:48 ` [RFC 0/6] Migration deprecated parts Jiri Denemark

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=875y7sflqb.fsf@secure.mitica \
    --to=quintela@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=eblake@redhat.com \
    --cc=fam@euphon.net \
    --cc=leobras@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=thuth@redhat.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;
as well as URLs for NNTP newsgroup(s).