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