On 12/23/20 7:09 PM, Zhang Chen wrote:
> From: Zhang Chen <chen.zh...@intel.com>
> 
> Since the real user scenario does not need to monitor all traffic.
> Add colo-passthrough-add and colo-passthrough-del to maintain
> a COLO network passthrough list.
> 
> Signed-off-by: Zhang Chen <chen.zh...@intel.com>

> --- a/qapi/net.json
> +++ b/qapi/net.json
> @@ -714,3 +714,49 @@
>  ##
>  { 'event': 'FAILOVER_NEGOTIATED',
>    'data': {'device-id': 'str'} }
> +
> +##
> +# @colo-passthrough-add:
> +#
> +# Add passthrough entry according to customer's needs in COLO-compare.
> +#
> +# @protocol: COLO passthrough just support TCP and UDP.
> +#
> +# @port: TCP or UDP port number.
> +#
> +# Returns: Nothing on success
> +#
> +# Since: 5.3

The next release is 6.0, not 5.3.

> +#
> +# Example:
> +#
> +# -> { "execute": "colo-passthrough-add",
> +#      "arguments": { "protocol": "tcp", "port": 3389 } }
> +# <- { "return": {} }
> +#
> +##
> +{ 'command': 'colo-passthrough-add',
> +     'data': {'protocol': 'str', 'port': 'uint32'} }

Should 'protocol' be an enum (finite set of values) rather than an
open-coded string (infinite number of values, even though you mentioned
in the docs above that only 'tcp' or 'udp' make sense)?  In fact, do we
already have existing QAPI types representing tcp/udp and a port number
that could be reused here, rather than open-coding yet another one?

> +
> +##
> +# @colo-passthrough-del:
> +#
> +# Delete passthrough entry according to customer's needs in COLO-compare.
> +#
> +# @protocol: COLO passthrough just support TCP and UDP.
> +#
> +# @port: TCP or UDP port number.
> +#
> +# Returns: Nothing on success
> +#
> +# Since: 5.3

another 6.0 spot

> +#
> +# Example:
> +#
> +# -> { "execute": "colo-passthrough-del",
> +#      "arguments": { "protocol": "tcp", "port": 3389 } }
> +# <- { "return": {} }
> +#
> +##
> +{ 'command': 'colo-passthrough-del',
> +     'data': {'protocol': 'str', 'port': 'uint32'} }
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org


Reply via email to