On 02/25/2015 03:03 AM, Laine Stump wrote:
On 02/24/2015 01:48 PM, John Ferlan wrote:
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.
Yes, I agree with this. In the other uses of "family", when it isn't
specified it is assumed to be ipv4, not "either" (mostly for historical
reasons, but it makes sense).
Okay, thanks a lot for your help
i will use family=ipv4|ipv6
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.
Definitely.
Dealing with new attributes is always a bit tricky...
Luyao
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list