From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Fabiano Rosas <farosas@suse.de>
Cc: qemu-devel@nongnu.org, Peter Xu <peterx@redhat.com>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [RFC PATCH 05/13] migration: Reduce a bit of duplication in migration.json
Date: Mon, 14 Apr 2025 17:38:01 +0100 [thread overview]
Message-ID: <Z_056amMGN6Ey_1i@redhat.com> (raw)
In-Reply-To: <20250411191443.22565-6-farosas@suse.de>
On Fri, Apr 11, 2025 at 04:14:35PM -0300, Fabiano Rosas wrote:
> Introduce a new MigrationConfigBase, to allow most of the duplication
> in migration.json to be eliminated.
>
> The reason we need MigrationParameters and MigrationSetParameters is
> that the internal parameter representation in the migration code, as
> well as the user-facing return of query-migrate-parameters use one
> type for the TLS options (tls-creds, tls-hostname, tls-authz), while
> the user-facing input from migrate-set-parameters uses another.
>
> The difference is in whether the NULL values is accepted. The former
> considers NULL as invalid, while the latter doesn't.
>
> Move all other (non-TLS) options into the new type and make it a base
> type for the two diverging types so that each child type can declare
> the TLS options in its own way.
>
> Nothing changes in the user API, nothing changes in the internal
> representation, but we save several lines of duplication in
> migration.json.
>
> Signed-off-by: Fabiano Rosas <farosas@suse.de>
> ---
> qapi/migration.json | 358 +++++++++++++-------------------------------
> 1 file changed, 108 insertions(+), 250 deletions(-)
>
> diff --git a/qapi/migration.json b/qapi/migration.json
> index 8b9c53595c..5a4d5a2d3e 100644
> --- a/qapi/migration.json
> +++ b/qapi/migration.json
> @@ -914,202 +914,6 @@
> @@ -1277,45 +1059,121 @@
> # only has effect if the @mapped-ram capability is enabled.
> # (Since 9.1)
> #
> +# @tls: Whether to use TLS. If this is set the options @tls-authz,
> +# @tls-creds, @tls-hostname are mandatory and a valid string is
> +# expected. (Since 10.1)
> +#
I'm not really finding it compelling to add a bool @tls as it
is just a denormalization of !!@tls-creds.
Incidentally the docs here are wrong - TLS can be used by
only setting @tls-creds. The @tls-authz & @tls-hostname
params are always optional.
> # Features:
> #
> # @unstable: Members @x-checkpoint-delay and
> # @x-vcpu-dirty-limit-period are experimental.
> #
> +# Since: 10.1
> +##
> +{ 'struct': 'MigrationConfigBase',
> + 'data': { '*announce-initial': 'size',
> + '*announce-max': 'size',
> + '*announce-rounds': 'size',
> + '*announce-step': 'size',
> + '*throttle-trigger-threshold': 'uint8',
> + '*cpu-throttle-initial': 'uint8',
> + '*cpu-throttle-increment': 'uint8',
> + '*cpu-throttle-tailslow': 'bool',
> + '*max-bandwidth': 'size',
> + '*avail-switchover-bandwidth': 'size',
> + '*downtime-limit': 'uint64',
> + '*x-checkpoint-delay': { 'type': 'uint32',
> + 'features': [ 'unstable' ] },
> + '*multifd-channels': 'uint8',
> + '*xbzrle-cache-size': 'size',
> + '*max-postcopy-bandwidth': 'size',
> + '*max-cpu-throttle': 'uint8',
> + '*multifd-compression': 'MultiFDCompression',
> + '*multifd-zlib-level': 'uint8',
> + '*multifd-qatzip-level': 'uint8',
> + '*multifd-zstd-level': 'uint8',
> + '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ],
> + '*x-vcpu-dirty-limit-period': { 'type': 'uint64',
> + 'features': [ 'unstable' ] },
> + '*vcpu-dirty-limit': 'uint64',
> + '*mode': 'MigMode',
> + '*zero-page-detection': 'ZeroPageDetection',
> + '*direct-io': 'bool',
> + '*tls': 'bool' } }
> { 'struct': 'MigrationParameters',
> + 'base': 'MigrationConfigBase',
> + 'data': { 'tls-creds': 'str',
> + 'tls-hostname': 'str',
> + 'tls-authz': 'str' } }
snip
> +{ 'struct': 'MigrateSetParameters',
> + 'base': 'MigrationConfigBase',
> + 'data': { '*tls-creds': 'StrOrNull',
> + '*tls-hostname': 'StrOrNull',
> + '*tls-authz': 'StrOrNull' } }
I recall we discussed this difference a year or two ago, but can't
recall what the outcome was.
Making the TLS params optional is a back compatible change for
MigrationParameters. I would think replacing 'str' with 'StrOrNull'
is also back compatible. So I'm wondering if we can't just unify
the sttructs fully for TLS, even if one usage scenario never actually
needs the "OrNull" bit nor needs the optionality
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2025-04-14 16:38 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-11 19:14 [RFC PATCH 00/13] migration: Unify capabilities and parameters Fabiano Rosas
2025-04-11 19:14 ` [RFC PATCH 01/13] migration: Fix latent bug in migrate_params_test_apply() Fabiano Rosas
2025-04-11 19:14 ` [RFC PATCH 02/13] migration: Normalize tls arguments Fabiano Rosas
2025-04-14 16:30 ` Daniel P. Berrangé
2025-04-11 19:14 ` [RFC PATCH 03/13] migration: Run a post update routine after setting parameters Fabiano Rosas
2025-05-15 20:42 ` Peter Xu
2025-04-11 19:14 ` [RFC PATCH 04/13] migration: Fix parameter validation Fabiano Rosas
2025-05-15 20:59 ` Peter Xu
2025-05-22 16:39 ` Fabiano Rosas
2025-05-22 17:39 ` Fabiano Rosas
2025-05-26 13:09 ` Peter Xu
2025-05-26 15:41 ` Fabiano Rosas
2025-04-11 19:14 ` [RFC PATCH 05/13] migration: Reduce a bit of duplication in migration.json Fabiano Rosas
2025-04-14 16:38 ` Daniel P. Berrangé [this message]
2025-04-14 17:02 ` Fabiano Rosas
2025-04-16 13:38 ` Markus Armbruster
2025-04-16 14:41 ` Fabiano Rosas
2025-04-17 5:56 ` Markus Armbruster
2025-04-17 18:45 ` Markus Armbruster
2025-04-18 6:40 ` Markus Armbruster
2025-04-11 19:14 ` [RFC PATCH 06/13] migration: Remove the parameters copy during validation Fabiano Rosas
2025-04-11 19:14 ` [RFC PATCH 07/13] migration: Introduce new MigrationConfig structure Fabiano Rosas
2025-04-18 7:03 ` Markus Armbruster
2025-05-23 13:38 ` Fabiano Rosas
2025-05-26 7:37 ` Markus Armbruster
2025-04-11 19:14 ` [RFC PATCH 08/13] migration: Replace s->parameters with s->config Fabiano Rosas
2025-04-11 19:14 ` [RFC PATCH 09/13] migration: Do away with usage of QERR_INVALID_PARAMETER_VALUE Fabiano Rosas
2025-04-11 19:14 ` [RFC PATCH 10/13] migration: Replace s->capabilities with s->config Fabiano Rosas
2025-04-11 19:14 ` [RFC PATCH 11/13] migration: Merge parameters and capability checks Fabiano Rosas
2025-04-11 19:14 ` [RFC PATCH 12/13] [PoC] migration: Add query/set commands for MigrationConfig Fabiano Rosas
2025-05-26 7:51 ` Markus Armbruster
2025-05-27 22:14 ` Fabiano Rosas
2025-04-11 19:14 ` [RFC PATCH 13/13] [PoC] migration: Allow migrate commands to provide the migration config Fabiano Rosas
2025-05-26 8:03 ` Markus Armbruster
2025-05-26 15:10 ` Peter Xu
2025-04-14 16:44 ` [RFC PATCH 00/13] migration: Unify capabilities and parameters Daniel P. Berrangé
2025-04-14 17:12 ` Fabiano Rosas
2025-04-14 17:20 ` Daniel P. Berrangé
2025-04-14 17:40 ` Fabiano Rosas
2025-04-14 19:06 ` Daniel P. Berrangé
2025-05-15 20:21 ` Peter Xu
2025-04-16 13:44 ` Markus Armbruster
2025-04-16 15:00 ` Fabiano Rosas
2025-04-24 9:35 ` Markus Armbruster
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=Z_056amMGN6Ey_1i@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=farosas@suse.de \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).