Bug 1098029

   It collects the log from the rhsc-engine first before asking for password, so it takes that much time.

   To elaborate, it executes the following command to collect the logs related to engine, because of which there is a delay:

sosreport --batch --report --build --tmp-dir=/tmp/logcollector-Rk5etx -o engine,rpm,libvirt,general,networking,hardware,process,yum,filesys,devicemapper,selinux,kernel,apache,memory,ovirt_engine_dwh,ovirt_engine_reports -k rpm.rpmva=off -k general.all_logs=True -k apache.log=True -k engine.sensitive_keys=:ENGINE_DB_PASSWORD:ENGINE_PKI_TRUST_STORE_PASSWORD:ENGINE_PKI_ENGINE_STORE_PASSWORD

(In reply to Darshan from comment #1)
>    It collects the log from the rhsc-engine first before asking for
> password, so it takes that much time.
> 
>    To elaborate, it executes the following command to collect the logs
> related to engine, because of which there is a delay:
> 
> sosreport --batch --report --build --tmp-dir=/tmp/logcollector-Rk5etx -o
> engine,rpm,libvirt,general,networking,hardware,process,yum,filesys,
> devicemapper,selinux,kernel,apache,memory,ovirt_engine_dwh,
> ovirt_engine_reports -k rpm.rpmva=off -k general.all_logs=True -k
> apache.log=True -k
> engine.sensitive_keys=:ENGINE_DB_PASSWORD:ENGINE_PKI_TRUST_STORE_PASSWORD:
> ENGINE_PKI_ENGINE_STORE_PASSWORD


If this is the current behaviour, then it has to fixed as it doesn't seems to be the right way. It should either prompt for the password before it start collecting the engine logs or it should show the progress of gathering the logs. I prefer the first one, i.e; prompting for the password before start gathering the engine logs due to the following condition:

* Lets assume that log-collector succesfully gathered all the engine logs
* Then iIt prompted for the REST API password
* User gave a wrong passsword 
So 
In the above case, the whole command fails at the middle of the process. Is it not better and makes more sense if it prompts for the password first and fails right away on an invalid entry?? If not, what do you suggest??

(In reply to Prasanth from comment #2)

> * Lets assume that log-collector succesfully gathered all the engine logs
> * Then iIt prompted for the REST API password
> * User gave a wrong passsword 
> So 
> In the above case, the whole command fails at the middle of the process. Is
> it not better and makes more sense if it prompts for the password first and
> fails right away on an invalid entry?? If not, what do you suggest??

I agree, make sense ask password before start log collection.
Note that if engine is down we need to be sure that log collector can collect engine host logs in any case. So a failure connecting to the engine should not cause log collector to exit.

(In reply to Sandro Bonazzola from comment #3)
> (In reply to Prasanth from comment #2)
> 
> > * Lets assume that log-collector succesfully gathered all the engine logs
> > * Then iIt prompted for the REST API password
> > * User gave a wrong passsword 
> > So 
> > In the above case, the whole command fails at the middle of the process. Is
> > it not better and makes more sense if it prompts for the password first and
> > fails right away on an invalid entry?? If not, what do you suggest??
> 
> I agree, make sense ask password before start log collection.
> Note that if engine is down we need to be sure that log collector can
> collect engine host logs in any case. So a failure connecting to the engine
> should not cause log collector to exit.

Sandro and Prasanth, 

I originally designed the LC to explicitly not ask for the password upon launch because you don't need the PW to collect logs from the RHEV-M.  Hence, I didn't want to gate the collection of these logs on a non-responsive RHEV-M.  Translation... some logs are better than no logs.

I have no problem with this behavior changing as long as a non-responsive RHEV-M will not force the user to supply the 'no-hypervisors' option.

Keith

Verified in rhsc-log-collector-3.0.0-3.0.el6rhs

------------
# rhsc-log-collector 
Please provide the REST API password for the admin@internal oVirt Engine user (CTRL+D to skip): 
INFO: Gathering oVirt Engine information...
INFO: Gathering PostgreSQL the oVirt Engine database and log files from localhost...
About to collect information from 3 servers. Continue? (Y/n): y
INFO: Gathering information from selected servers...
INFO: collecting information from 10.70.43.69
INFO: Gluster logs will be collected from 10.70.43.69
INFO: collecting information from 10.70.42.241
INFO: Gluster logs will be collected from 10.70.42.241
INFO: collecting information from 10.70.42.167
INFO: Gluster logs will be collected from 10.70.42.167
INFO: finished collecting information from 10.70.43.69
INFO: finished collecting information from 10.70.42.167
INFO: finished collecting information from 10.70.42.241
Creating compressed archive...
INFO: Log files have been collected and placed in /tmp/sosreport-LogCollector-20140612130910.tar.xz.
The MD5 for this file is 5c5e3a39a229a9d8c07dc03fd6cefde3 and its size is 54.1M
------------

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

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

http://rhn.redhat.com/errata/RHEA-2014-1277.html