Re: [PATCH v3 12/20] migration: Change HMP 'info migrate_parameters' output

[Markus Armbruster <armbru@redhat.com>]

Fabiano Rosas <farosas@suse.de> writes:

> The output of 'info migrate_parameters' includes units of measurement
> for a few parameters. This is convenient for a user. However, having
> the units also means that every parameter must have its own separate
> piece of code to handle the formatting.
>
>>From a development and maintenance perspective, having a list of
> parameters explicitly written in several parts of the code brings
> annoyances: conflicts during rebase, extra hits when grepping,
> contributors need to mirror a change to various locations, etc.
>
> As the HMP output is not part of any ABI, remove the units from the
> output to avoid this requirement of having individualized code for
> every parameter. Next patches will take benefit from that and use
> generic code to output the parameters values in HMP.
>
> Aside from the units, also remove quotes from around the TLS options
> strings as this is inconsistent with all the other strings.
>
> Similarly, change block-bitmap-mapping format to remove the arrows
> (->) for the mappings as not all parameters represented as a list have
> this semantics. This requires updating one of the iotests.
>
> Before:                                      After:
>                      (unchanged entries omitted)
> announce-initial: 50 ms                      announce-initial: 50
> announce-max: 550 ms                         announce-max: 550
> announce-rounds: 5                           announce-rounds: 5
> announce-step: 100 ms                        announce-step: 100
> tls-creds: ''                                tls-creds:
> tls-hostname: ''                             tls-hostname:
> tls-authz: ''                                tls-authz:
> max-bandwidth: 134217728 bytes/second        max-bandwidth: 134217728
> avail-switchover-bandwidth: 0 bytes/second   avail-switchover-bandwidth: 0
> max-postcopy-bandwidth: 0 bytes/second       max-postcopy-bandwidth: 0
> downtime-limit: 300 ms                       downtime-limit: 300
> x-checkpoint-delay: 20000 ms                 x-checkpoint-delay: 20000
> xbzrle-cache-size: 67108864 bytes            xbzrle-cache-size: 67108864
> x-vcpu-dirty-limit-period: 1000 ms           x-vcpu-dirty-limit-period: 1000
> vcpu-dirty-limit: 1 MB/s                     vcpu-dirty-limit: 1
> x-rdma-chunk-size: 1048576 bytes             x-rdma-chunk-size: 1048576
> block-bitmap-mapping:                        block-bitmap-mapping:
>   'node-src' -> 'node-dst'                    bitmaps:
>     'bmap0' -> 'bmap0'                        name: bmap0 alias: bmap0
>                                               node-name: node-src alias: node-dst

I think the value of block-bitmap-mapping could be more legible.

@block-bitmap-mapping has the following structure (using JSON as
notation):

    [{"node-name": NODE-NAME1, "alias": NODE-ALIAS1,
      "bitmaps": [{"name": BITMAP-NAME1.1, "alias": BITMAP-ALIAS1.1,
                   "transform": {"persistent": PERS1.1}}
                  {"name": BITMAP-NAME1.2, "alias": BITMAP-ALIAS1.2,
                   "transform": {"persistent": PERS1.2}},
                   ...]},
     {"node-name": NODE-NAME2, "alias": NODE-ALIAS2,
      "bitmaps": [{"name": BITMAP-NAME2.1, ...}, ...]},
      ...]

As far as I can tell, it gets formatted like

    block-bitmap-mapping:
     bitmaps:
     name: BITMAP-NAME1.1 transform: persistent: PERS1.1 alias: ALIAS-NAME1.1
     name: BITMAP-NAME1.2 transform: persistent: PERS1.2 alias: ALIAS-NAME1.2
     node-name: NODE-NAME1 alias: NODE-ALIAS1
     name: BITMAP-NAME2.1 ...
     node-name: NODE-NAME2 alias: NODE-ALIAS2

Suggest to do it more like this

    block-bitmap-mapping:
      node-name: NODE-NAME1 alias: NODE-ALIAS1
        bitmaps:
          name: BITMAP-NAME1.1 alias: BITMAP-ALIAS1.1 persistent: PERS1.1
          name: BITMAP-NAME1.2 alias: BITMAP-ALIAS1.2 persistent: PERS1.2
      node-name: NODE-NAME2 alias: NODE-ALIAS2
        bitmaps:
          name: BITMAP-NAME2.1 ...

Or just dump as pretty-printed JSON and call it good.