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