Blame SOURCES/0060-v2v-rhv-upload-plugin-Fix-name-error.patch

e9bfca
From 19d61962acdb3afa377631dc2d6658e8e73ac9ac Mon Sep 17 00:00:00 2001
e9bfca
From: Nir Soffer <nirsof@gmail.com>
e9bfca
Date: Mon, 25 Jun 2018 20:56:52 +0300
e9bfca
Subject: [PATCH] v2v: rhv-upload-plugin: Fix name error
e9bfca
e9bfca
"http" and "transfer" variables were missing in emulate_zero, so the
e9bfca
code would fail with NameError.  This can happen only when communicating
e9bfca
with old imageio versions not supporting the "zero" feature.
e9bfca
e9bfca
Testing with qemu-img 2.12 show that we never send emulated zero request
e9bfca
because of the highestwrite mechanism, but it can break with older
e9bfca
qemu-img-rhev used on RHEL.
e9bfca
e9bfca
(cherry picked from commit 0ae61ce99c351f9cda598016fb55ccc50313df67)
e9bfca
---
e9bfca
 v2v/rhv-upload-plugin.py | 3 +++
e9bfca
 1 file changed, 3 insertions(+)
e9bfca
e9bfca
diff --git a/v2v/rhv-upload-plugin.py b/v2v/rhv-upload-plugin.py
e9bfca
index 2eec375f7..10887c031 100644
e9bfca
--- a/v2v/rhv-upload-plugin.py
e9bfca
+++ b/v2v/rhv-upload-plugin.py
e9bfca
@@ -338,6 +338,9 @@ def zero(h, count, offset, may_trim):
e9bfca
     r.read()
e9bfca
 
e9bfca
 def emulate_zero(h, count, offset):
e9bfca
+    http = h['http']
e9bfca
+    transfer = h['transfer']
e9bfca
+
e9bfca
     # qemu-img convert starts by trying to zero/trim the whole device.
e9bfca
     # Since we've just created a new disk it's safe to ignore these
e9bfca
     # requests as long as they are smaller than the highest write seen.
e9bfca
-- 
e9bfca
2.17.1
e9bfca