This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 831917 - image-uploader - deprecate support for importing same image multiple times
image-uploader - deprecate support for importing same image multiple times
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-image-uploader (Show other bugs)
unspecified
Unspecified Unspecified
high Severity unspecified
: ---
: ---
Assigned To: Keith Robertson
yeylon@redhat.com
integration
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-14 01:02 EDT by Itamar Heim
Modified: 2016-07-03 21:36 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-15 05:10:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Itamar Heim 2012-06-14 01:02:37 EDT
now than engine supports importing more than once, seems redudnant to maintain this logic in image-uploader as well.

only problem is we wouldn't want customers of 3.0 getting this new image-uploader, so should probably require the new engine rpm version wise.
Comment 1 Andrew Cathrow 2012-06-14 08:47:05 EDT
Itamar, do we want to do this for 3.1 or push to rhevm-future?
Comment 2 Keith Robertson 2012-06-14 09:12:49 EDT
As I think about it some more ... there is one use case where it might make sense to have the tool edit the OVF XML.  It is blanking the NIC's MAC addr so that the engine import will reassign/reallocate.  From a functional point of view this isn't very hard to do because it doesn't involve allocating uuids, renaming files, etc.
Comment 3 Itamar Heim 2012-06-14 09:19:40 EDT
(In reply to comment #1)
> Itamar, do we want to do this for 3.1 or push to rhevm-future?

we can think about this a bit longer.
we can also consider just announcing deprecation of these features and not fixing bugs around them for now.
my fear is it will cause more people using it this way, and harder to deprecate later.

(In reply to comment #2)
> As I think about it some more ... there is one use case where it might make
> sense to have the tool edit the OVF XML.  It is blanking the NIC's MAC addr
> so that the engine import will reassign/reallocate.  From a functional point
> of view this isn't very hard to do because it doesn't involve allocating
> uuids, renaming files, etc.

i'd argue the marketplace OVF should have these empty already.
but true for moving between two rhev-m's.
Comment 4 Itamar Heim 2012-08-15 05:10:50 EDT
closing as this is a release note on deprecating this support.

Note You need to log in before you can comment on or make changes to this bug.