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

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