[libvirt] [PATCH 2/4] conf: introduce new family attribute in graphics listen for chose IP family

Laine Stump laine at laine.org
Tue Feb 24 19:03:34 UTC 2015


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).

>
> 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...
>
>




More information about the libvir-list mailing list