On Wed, Nov 26, 2014 at 09:02:28AM -0500, John Ferlan wrote:
On 11/26/2014 08:21 AM, Eric Blake wrote:On 11/26/2014 01:33 AM, Martin Kletzander wrote:This reverts commit 433b427ff853ab72d32573d415e6ec569b77c7cb. The patch was added in order to overcome a bug in iproute2 and since it was properly identified as a bug, particularly in openSUSE 13.2, and it is being worked on [1], the best solution for libvirt seems to be to keep the old behaviour. [1] https://bugzilla.novell.com/show_bug.cgi?id=907093 --- src/util/virnetdevveth.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)I'm 50:50 on this one. The workaround case is arguably more legible, and is understood by all versions of iproute2 (including the buggy SUSE release), so it's not like it is that ugly of a workaround. The revert is clean if you want to do it, but I don't see any compelling reason requiring us to revert. Maybe someone else can swing the vote.Given the following - I think I'd be more in favor of the revert. Perhaps not exactly the same thing, but consider the posix_fallocate() issue with NFS for which I tried to submit workaround patches for, but was instead asked to submit a bug against glibc, see: http://www.redhat.com/archives/libvir-list/2014-August/msg00491.html So we didn't accept a workaround in this case and although this iproute2 issue has a much more expedient fix than posix_fallocate (still waiting, btw) - the decision was to leave the libvirt code 'buggy' until the root cause was fixed. So translate that here - if we revert this change then it seems for one version of iproute2 there's a bug. Seems this is easily document-able if we remove the patch (as ugly as the documentation could be). It seems the issue in keeping the code as is runs the risk that there is some iproute2 that doesn't understand or process the 'name' syntax, which is an unknown and could cause "other" failures... Hence, my vote for revert
It looks like we have more people wanting the old behaviour, If there's no new vote against that for few hours, I'm pushing this. Thanks for discussing this, Martin
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list