[libvirt PATCH 09/10] conf: extra validation for <portOptions isolated='yes'/>

Ján Tomko jtomko at redhat.com
Wed Feb 19 09:41:04 UTC 2020


On Tue, Feb 18, 2020 at 10:08:42PM -0500, Laine Stump wrote:
>On 2/18/20 12:52 PM, Ján Tomko wrote:
>>On Sun, Feb 16, 2020 at 11:22:58PM -0500, Laine Stump wrote:
>>>During the hypervisor-agnostic validation of network devices, verify
>>>that the interface type is either "network" or "bridge", and that if
>>>there is any <virtualport>, that it doesn't have any type associated
>>>with it.
>>>
>>>This needs to be done both for the parse-time validation and for
>>>runtime validation (after a port has been acquired from any associated
>>>network), because an interface with type='network' could have an
>>>actual type at runtime of "hostdev" or "direct", neither of which
>>>support isolated='true' (yet). Likewise, if an interface is
>>>type='network', then at runtime a <virtualport> with a type that
>>>doesn't support isolated='yes' (e.g. "openvswitch", "802.1Qbh" -
>>>currently *none* of the available virtualport types support it)
>>>
>>>Signed-off-by: Laine Stump <laine at redhat.com>
>>>---
>>>src/conf/domain_conf.c | 56 ++++++++++++++++++++++++++++++++++++++++++
>>>1 file changed, 56 insertions(+)
>>>
>>>diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
>>>index 30b2a53b83..f8ce7d519d 100644
>>>--- a/src/conf/domain_conf.c
>>>+++ b/src/conf/domain_conf.c

[...]

>>>+            virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
>>>+                           _("interface %s - <portOptions 
>>>isolated='yes'/> is not supported for network interfaces with 
>>>type='%s'"),
>>
>>Please don't put XML snippets in the error message.
>
>Because... ?

My reasoning was that it takes more space - especially the ='yes'
part is redundant. And I thought we never do that, which is apparently
not true:

   $ git grep '_(.*"<' src/conf/ | wc -l
   7

>
>>How about:
>>     ... - isolated ports are not supported ...
>
>Wouldn't that make it more likely that the word "isolated" (and maybe 
>even "port") would be translated, and the resulting error message less 
>useful to the end user? If it's explicitly an XML element or 
>attribute, then at least a translator who knew a bit about libvirt 
>would realize that it's the name of an element/attribute and shouldn't 
>be translated.

Right, leave it in then.

>
>(But maybe there was a discussion about this somewhere, it was 
>debated, and I missed it. If that's become a rule of log messages then 
>of course I'll follow it.)

Not that I know of.

Jano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200219/4069f7ce/attachment-0001.sig>


More information about the libvir-list mailing list