Bug 862260

Summary: [RFE] engine-iso-uploader: update command-line usage (URL based location, etc.)
Product: [oVirt] ovirt-iso-uploader Reporter: Alon Bar-Lev <alonbl>
Component: CoreAssignee: Sandro Bonazzola <sbonazzo>
Status: CLOSED DEFERRED QA Contact: Pavel Stehlik <pstehlik>
Severity: low Docs Contact:
Priority: medium    
Version: ---CC: bsettle, bugs, dfediuck, didi, jbelka, ldelouw, lveyde, mgoldboi, rbalakri, Rhev-m-bugs, rmartins, sbonazzo, stirabos, ylavi
Target Milestone: ---Keywords: FutureFeature, Improvement
Target Release: ---Flags: sbonazzo: ovirt-future?
rule-engine: planning_ack?
sbonazzo: devel_ack?
rule-engine: testing_ack?
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-06-07 21:28:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Integration RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Alon Bar-Lev 2012-10-02 13:34:22 UTC
CURRENT STATUS

engine-iso-uploader command-line interface is hard to use, there is no explicit method to select transport (ssh, nfs), there is implicit behaviour, such as if one specifies ssh user then ssh is used.

It is also hard to understand how it can be used with or without engine, and it is very hard to extend in coherent approach.

SUGGESTION

Alter the command-line interface to be similar to other network tools, by making it URL based.

Usage:

engine-iso-uploader [options] command source [source...] destination
    -c|--config file - read configuration from file.
    -o|--option option=value - set configuration option
    --engine - engine to use (rest api) URL notation.
    command
        list - list iso images
        upload - upload iso images
        download - download iso images
    source - URL of source.
    destination - URL of destination.

URL notation:
    protocol://user:password@host:port/path?arguments

Supported local destinations:
    file://path
    /path

Supported remote destinations:
    nfs://*ISO_DOMAIN - '*' marks host as iso domain, query location from server.
    nfs://host/path - bypass engine, put image directly at path.
    ssh://host/path - bypass engine, put image directly at path.

Configuration file
    netrc=<file> default:~/.netrc
    engine=<url>
    ssh-key=<file>

Password prompt
    If URL is missing password and password is not provided within netrc

BENEFITS

1. Using URL notation to provide locations obsoletes the need to specify protocol, host, port, user, password, path. It is standard notation known by target audience.

2. Using well formed command: utility command source... destination is commonly used for transfers.

3. Using standard netrc notation to provide host credentials is better than proprietary format.

4. Using options as name=value provides the ability to extend configuration without altering the command-line usage.

Comment 1 Alon Bar-Lev 2012-10-02 13:37:25 UTC
This was discussed some time ago with Keith Robertson and Itamar Heim.

Comment 2 Sandro Bonazzola 2013-03-19 07:46:50 UTC
Maybe we want also a list-domains command in order to preserve the functionality provided by current list command.

Having also the download command could be useful. Maybe ovirt-engin-iso-uploader will be reductive for the tool, ovirt-engine-iso-ctl or ovirt-engine-iso-manager could be more appropriate.

Comment 3 Alon Bar-Lev 2013-03-19 09:12:55 UTC
We should merge the image and iso uploaders into single tool

Comment 4 Jiri Belka 2013-04-16 10:10:35 UTC
If there is only one ISO domain, does engine-iso-uploader have to ask for its name? This is sooooo annoying.

Comment 5 Sandro Bonazzola 2015-04-07 13:11:41 UTC
Doesn't seems weekathon material to me.

Comment 7 Sandro Bonazzola 2017-03-06 15:36:17 UTC
Yaniv, can we close this one since ovirt-iso-uploader is deprecated in favor of ovirt-imageio?

Comment 8 Yaniv Lavi 2017-03-09 10:37:58 UTC
I would wait for the replacement feature to be in.

Comment 9 Yaniv Kaul 2017-06-07 21:28:54 UTC
(In reply to Yaniv Lavi from comment #8)
> I would wait for the replacement feature to be in.

We are not going to change the command line nevertheless. Closing for the time being.