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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list