On 02/24/2015 01:09 PM, Laine Stump wrote: > On 02/24/2015 12:42 PM, John Ferlan wrote: >> <...snip...> >> I see family as a "tristate" value. That is not provided is 0 and not >> printed... Thus, the value turns into tristate where of ipv6='yes|no', >> where the default is no. > > There is precedent in libvirt config for a "family" which can be set to > ipv6 or ipv4 or not be set at all (e.g. see the <ip> and <route> > elements in a libvirt network). I agree that "default" shouldn't be an > allowed setting, but I think we can/should stick with family for the > attribute rather than ipv6='(yes|no)' > > OK - fair enough. Going the family=ipv4|ipv6 is fine - perhaps a mix and match of what I've looked at and responded to so far. If IPv4 is provided, then we require to find an IPv4 address, same for IPv6... If the attribute is not provided, then we have to assume return of IPv4 address because the point I raised in patch 3/4 where the caller should be the one to decide whether it can accept/process a returned IPv6 address in the (unlikely?) scenario that an IPv4 address wasn't found. Since the default today is to attempt to return an IPv4 address, we're almost forced to ensure that the caller/user lets us know they want and can handle either address style. The problem I see with generating "family='ipv4'" or "family=" on output if not provided on input is that we end up with test case regressions and the possibility of issues with someone trying to "move" their XML to some other system that doesn't yet understand the new attribute. Dealing with new attributes is always a bit tricky... John <...snip...> -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list