[libvirt] [PATCH 0/8] (incomplete) fix of "peer" address feature

[Andrea Bolognani]

On Thu, 2016-04-28 at 10:51 -0400, Laine Stump wrote:
> This patch series fixes this feature enoough that it works:
> 
> 1) emits "peer" attribute in formatted XML when present in the NetDef
>    object, so that the config will "stick"
> 
> 2) swaps "address" and "peer" for qemu, so that "address" consistently
>    refers to the IP address used by the guest, and "peer" to the address
>    used by the host.
> 
> 3) ... and the rest
> 
> *BUT* it doesn't address the sub-optimal naming of the new attribute,
> nor does it fix the documentation which is incorrect not only in its
> description, but also in the starting version number for QEMU
> support. Also, I'm skeptical that this new feature is useful for the
> types of lxc interfaces that are supported (macvtap i.e. "direct", and
> a veth connected to a bridge) - from my understanding, it would only
> be useful for a type='ethernet' interface (a tap/veth pair not
> connected to any bridge), and that isn't supported by lxc yet; for
> type='bridge' and type='network' (which is also connecting to a
> bridge) I don't see the use case.
> 
> So I'm torn about whether these patches should be put in for this
> release in order to made the already-pushed code work, or if we should
> just hold off until we:
> 
> 1) find/agree on a better name for the new attribute (see my earlier
>    mail titled 'interface "peer address" patches are broken for details
>    on my opinion)
> 
> 2) decide if it's actually useful to support the "peer" address for
>    type='network|bridge" in lxc (it isn't in qemu).
> 
> 3) fix the documentation (I started into that when I realized the 
> 
> By not pushing the fixes, we guarantee that nobody can use the
> feature, and thus will technically still be able to change the name of
> the attribute even after arelease has passed (because we won't break
> anyone's usable config).
> 
> Opinions on what to do?
> 
> (I would consider reverting the original patches temporarily until
> it's all sorted out, but I don't know what kind of conflicts that
> would cause; I know that there has been at least one bugfix patch)

I think reverting would be the best choice, assuming the result
looks safe enough; failing that, shipping the feature in a
shape that makes it unusable in practice seems preferable than
rushing naming decisions we'll have to live with forever.

-- 
Andrea Bolognani
Software Engineer - Virtualization Team