On Wed, Nov 11, 2020 at 03:41:59PM +0000, Dr. David Alan Gilbert wrote: > * Stefan Hajnoczi (stefa...@redhat.com) wrote: > > On Wed, Nov 11, 2020 at 12:56:26PM +0000, Dr. David Alan Gilbert wrote: > > > * Stefan Hajnoczi (stefa...@redhat.com) wrote: > > > > Orchestrating Migrations > > > > ------------------------ > > > > In order to migrate a device a *migration parameter list* must first be > > > > built > > > > on the source. Each migration parameter is added to the list if it is in > > > > effect. For example, the migration parameter list for a device with > > > > new-feature=off,num-queues=4 would be num-queues=4 if the new-feature > > > > migration > > > > parameter was introduced with the off value disabling its effect. > > > > > > What component builds that list (i.e. what component needs to know the > > > history that new-feature=off was the default - ah I think you answer > > > that below). > > > > Yep. Thanks for noting this. I'll need to reorder things so it is clear. > > > > > > The following conditions must be met to establish migration > > > > compatibility: > > > > > > > > 1. The source and destination device model strings match. > > > > > > > > 2. Each migration parameter name from the migration parameter list is > > > > supported > > > > by the destination. For example, the destination supports the > > > > num-queues > > > > migration parameter. > > > > > > > > 3. Each migration parameter value from the migration parameter list is > > > > supported by the destination. For example, the destination supports > > > > num-queues=4. > > > > > > Hmm, are combinations of parameter checks needed - i.e. is it possible > > > that a destination supports num-queues=4 and new-feature=on/off - > > > but only supports new-feature=on when num-queues>2 ? > > > > Yes, it's possible but cannot be expressed in the migration info JSON. > > > > We need to choose a level of expressiveness that will be useful enough > > without being complex. In the extreme the migration info would contain > > Turing complete validation expressions (e.g. JavaScript) so that any > > relationship can be expressed, but I doubt that complexity is needed. > > The other extreme is just booleans and (opaque) strings for maximum > > simplicity. > > > > If the syntax is not expressive enough then it's impossible to check > > migration compatibility without actually creating a new device instance > > on the destination. Daniel Berrange raised the requirement of checking > > migration compatibility without creating the device since this helps > > with selecting a migration destination. > > Right, but my worry isn't the JSON description, it's the set of 3 > conditions above; they need to state that only some combinations need to > be valid.
Yes, the proposed syntax is simply not expressive enough. The migration compatibility check will pass and then the destination will refuse to set up the device (before the device state is transferred). Any suggestions for a syntax without full-blown arithmetic and logic expressions? > > Any ideas for a better syntax? > > I'd be happy with a --param name=value repeatedly, but also know that > some option parsers don't like that. Another wart, Sphinx considers repeated options an error so you cannot document options using rST option syntax. I remember having this problem when documenting virtiofsd's command-line options :). If something comes to mind please let me know. I'm not set on a particular syntax, but I'd like to choose the one that is both human-friendly and compatible with option parsers while avoiding namespace collisions with the device implementation's own options. Stefan
signature.asc
Description: PGP signature
