Bug 1381223

Can't it be converted to use the image upload API?

(In reply to Yaniv Kaul from comment #1)
> Can't it be converted to use the image upload API?

It probably can, but what was the point of deprecating it in 4.0 if we want just to convert it instead of dropping it?

(In reply to Sandro Bonazzola from comment #2)
> (In reply to Yaniv Kaul from comment #1)
> > Can't it be converted to use the image upload API?
> 
> It probably can, but what was the point of deprecating it in 4.0 if we want
> just to convert it instead of dropping it?

I don't know why we need to deprecate it. It's a tool customers are familiar with. We may need to switch to the new mechanism for upload, but I personally not sure what other tool is available from the CLI to upload.

(In reply to Yaniv Kaul from comment #3)
> (In reply to Sandro Bonazzola from comment #2)
> > (In reply to Yaniv Kaul from comment #1)
> > > Can't it be converted to use the image upload API?
> > 
> > It probably can, but what was the point of deprecating it in 4.0 if we want
> > just to convert it instead of dropping it?
> 
> I don't know why we need to deprecate it. It's a tool customers are familiar
> with. We may need to switch to the new mechanism for upload, but I
> personally not sure what other tool is available from the CLI to upload.

I believe this should be used either from the SDKs or the API, which we will be adding in 4.1.

How does imageio cover the additional image-uploader features? 
like:
--mac-address: this tool will remove any network interface cards from the image to prevent conflicts with NICs on other VMs

--disk-instance-id: This ensures that there are no conflicts between the disks on the imported image and those within oVirt engine.

--ignore-lsc: Ignore free space errors on local  /tmp filesystem, useful with sparse files (default=off)

--force: replace like named files on the target file server

(In reply to Gonza from comment #5)
> How does imageio cover the additional image-uploader features? 
> like:
> --mac-address: this tool will remove any network interface cards from the
> image to prevent conflicts with NICs on other VMs
> 
> --disk-instance-id: This ensures that there are no conflicts between the
> disks on the imported image and those within oVirt engine.
> 
> --ignore-lsc: Ignore free space errors on local  /tmp filesystem, useful
> with sparse files (default=off)
> 
> --force: replace like named files on the target file server

All of these options are already covered by the engine validations.

Verified with:
ovirt-engine-4.1.0-0.2.master.20161205151239.git8f91a7d.el7.centos.noarch

It has been decided to unretir ovirt-image-uploader since ovirt-imageio is not able to handle OVAs and this will break several flows.
Postponing to 4.2.

Yaniv, can you open a bz on imageio with what's missing from ovirt-image-uploader and block this bug on it?

What's the status of this BZ?

(In reply to Yaniv Kaul from comment #10)
> What's the status of this BZ?

It was blocked waiting for 
Bug #1319758 - [RFE] Allow uploading a pre-existing VM image (OVA) into the environment
to be fixed providing a way to upload an OVA from the engine instead of using command line.
But now I read in https://bugzilla.redhat.com/show_bug.cgi?id=1319758#c4 that the engine won't be able to upload an ova, but just able to generate one and download it.

So the blocking bug is now bug #1049604 which should be the upload one which is still on POST and still targeted 4.2.0.
So, I'm keeping this in NEW targeted to 4.2.0 and will eventually not release ovirt-image-uploader in 4.2.0 GA if 1049604 will be fixed before GA.
Otherwise, I'll re-target this to 4.3.0 since once released I'm not going to drop the package in zstream.

Bug #1049604 is ON_QA in 4.2.1 so it's now possible to upload an ova using the web UI. I can now proceed removing ovirt-image-uploader from master.

In ovirt4.2, the ticket of uploadimage has a validity time of one hour. then when you click the recovery button, it will not apply for a new ticket, resulting in failure to recover and complete.But in ovirt4.1,the opertion has no problem,and why??

(In reply to zhao from comment #13)
> In ovirt4.2, the ticket of uploadimage has a validity time of one hour. then
> when you click the recovery button, it will not apply for a new ticket,
> resulting in failure to recover and complete.But in ovirt4.1,the opertion
> has no problem,and why??

Please open a bug on ovirt-imageio product: https://bugzilla.redhat.com/enter_bug.cgi?product=ovirt-imageio
Thanks.

ok, ovirt-engine-4.3.0-0.0.master.20180828114844.git0bc18b1.el7.noarch

# yum repolist -v | egrep -i 'baseurl.*ovirt'
Repo-baseurl : http://cbs.centos.org/repos/virt7-ovirt-common-testing/x86_64/os/
Repo-baseurl : http://cbs.centos.org/repos/virt7-ovirt-43-testing/x86_64/os/
Repo-baseurl : http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7Server/
Repo-baseurl : http://resources.ovirt.org/pub/ovirt-master-snapshot-static/rpm/el7Server/
Repo-baseurl : https://copr-be.cloud.fedoraproject.org/results/ovirtwebui/ovirt-web-ui/epel-7-x86_64/

# yum search ovirt-image-uploader
Loaded plugins: product-id, search-disabled-repos, versionlock
Warning: No matches found for: ovirt-image-uploader
No matches found

This bugzilla is included in oVirt 4.2.7 release, published on November 2nd 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.7 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.

Closed by mistake, moving back to qa -> verified

This bugzilla is included in oVirt 4.3.0 release, published on February 4th 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.3.0 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.