On Wed, Aug 23, 2023 at 03:26:25PM +0200, Markus Armbruster wrote:
> Peter Xu <pet...@redhat.com> writes:
>
> > These two structs are mostly identical besides some fields (quote from
> > Daniel P. Berrangé in his reply):
> >
> > 1c1
> > < { 'struct': 'MigrationParameters',
> > ---
> > > { 'struct': 'MigrateSetParameters',
> > 14,16c14,16
> > < '*tls-creds': 'str',
> > < '*tls-hostname': 'str',
> > < '*tls-authz': 'str',
> > ---
> > > '*tls-creds': 'StrOrNull',
> > > '*tls-hostname': 'StrOrNull',
> > > '*tls-authz': 'StrOrNull',
> >
> > Here the difference is @MigrateSetParameters object would allow 'null'
> > values for any tls-* fields passed in.
> >
> > Markus used to describe why it happened to be StrOrNull, and also his
> > concern on having a pure "str" type to be problematic as the reset
> > indicator in the commit 01fa559826 ("migration: Use JSON null instead of ""
> > to reset parameter to default"). There, "null" is introduced for the tls
> > fields even though being treated as "" (empty string) internally to match
> > the code.
>
> Suggest
>
> migration/qapi: Replace @MigrateSetParameters with @MigrationParameters
>
> migrate-set-parameters sets migration parameters, and
> query-migrate-parameters gets them. Unsurprisingly, the former's
> argument type MigrateSetParameters is quite close to the latter's
> return type MigrationParameters. The differences are subtle:
>
> 1. Since migrate-set-parameters supports setting selected parameters,
> its arguments must all be optional (so you can omit the ones you
> don't want to change). query-migrate-parameters results are also
> all optional, but almost all of them are in fact always present.
>
> 2. For parameters @tls_creds, @tls_hostname, @tls_authz,
> migrate-set-parameters interprets special value "" as "reset to
> default". Works, because "" is semantically invalid. Not a
> general solution, because a semantically invalid value need not
> exist. Markus added a general solution in commit 01fa559826
> ("migration: Use JSON null instead of "" to reset parameter to
> default"). This involved changing the type from 'str' to
> 'StrOrNull'.
>
> 3. When parameter @block-bitmap-mapping has not been set,
> query-migrate-parameters does not return it (absent optional
> member). Clean (but undocumented). When parameters @tls_creds,
> @tls_hostname, @tls_authz have not been set, it returns the
> semantically invalid value "". Not so clean (and just as
> undocumented).
>
> Items 2. and 3. need fact-checking.
For 2: "reset to default" is correct, assuming the default is not enabling
TLS. Or perhaps we can also say "TLS disabled" to be clear?
Currently in the code we rely on the string non-null (of tls-creds) to
detect whether tls is enabled in general for migration:
bool migrate_tls(void)
{
MigrationState *s = migrate_get_current();
return s->parameters.tls_creds && *s->parameters.tls_creds;
}
Definitely not as clean (which I agree..), but we probably need to keep it
working anyway.
>
> > Here to deduplicate the two objects, logically it'll be safe only if we use
> > "StrOrNull" to replace "str" type, not vice versa. However we may face
> > difficulty using StrOrNull as part of MigrationState.parameters [1] when
> > replacing existing @MigrationParameters to use StrOrNull. With the fact
> > that nobody seems to be using "null" for tls-* fields (see the long
> > standing qemu crash bug on tls-authz when "null" was passed in), let's use
> > "str" to represent both objects.
>
> "May face difficulty" is insufficiently strong to justify such
> incompatible change.
>
> I'll have a look at the difficulties you mentioned in [1]. If we can
> overcome them with reasonable effort, we can and should avoid the
> compatibility break. If we can't, we add proper rationale here.
Thanks, Markus. Just in case of anything helpful, I've pushed the other
version here:
https://github.com/xzpeter/qemu/tree/mig-param-dedup-strornull
--
Peter Xu
