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

[Luyao Huang]

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