Bug 643882

Summary:	TASKID vs. TASKSPEC inconsistency and a not very helpful error mesage
Product:	[Retired] Beaker	Reporter:	Izidor Matušov <imatusov>
Component:	command line	Assignee:	Bill Peck <bpeck>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	0.5	CC:	bpeck, dcallagh, jburke, kbaker, mcsontos, rmancy
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-08-22 23:36:53 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Izidor Matušov 2010-10-18 11:50:41 UTC

If I want to watch job 24470, I would like to enter the command:

[imatusov@imatusov ~]$ bkr job-watch 24470
Watching tasks (this may be safely interrupted)...
Exception: exceptions.ValueError:need more than 1 value to unpack

This error message doesn't say anything what's wrong. A similar bug is https://bugzilla.redhat.com/show_bug.cgi?id=595512 The workaround to this problem is to specify job as J:NNN, i.e. run bkr job-watch J:24470

What to repair?
1. Change the error message to something like "Incorrect format of job. It should be J:NNNN for job, RS:NNNN for recipe set, etc" or even better treat a number as a job number (and add J: in advance)

2. Add a paragraph about job identifying to help message.

3. Add a bit of usability: When the beaker is busy (like in the middle of work day), it takes about 5 minutes to connect there. Only afterwards the parameters are parsed. What does it imply? The user waits 5 minutes to just get error message.

Comment 1 Izidor Matušov 2010-10-19 09:34:17 UTC

Identifying tasks is not consistent. If I want to identify task for watchdog-extend, I can't use the same format as for job-watch (J:NNNN) but just NNNN. It is a little bit confusing.

[imatusov@imatusov ~]$ bkr watchdog-extend --by=999999 j:24650
Exception: bkr.server.bexceptions.BX:'Invalid task ID: j:24650'
[imatusov@imatusov ~]$ bkr watchdog-extend --by=999999 24650
...

Comment 2 Marian Csontos 2010-10-19 09:58:28 UTC

In case of watchdog-extend prepending anything would be just useless: there are watchdogs (WDs) for tasks only. No WDS for recipes or recipe-sets.

However, I agree it might accept "T:" prefix and reject other prefixes.

Anyway +1 for the idea of commands using default prefix if missing while required.

Comment 3 Izidor Matušov 2010-10-19 11:46:44 UTC

I don't say bkr watchdog-* should require prefixes. 

A good principle of creating (user) interfaces is to accept every correct input but the output should be always the same. I mean:

bkr watchdog-extend --by=999999 j:24650 && bkr watchdog-extend --by=999999 24650 are equal (they're just aliases)

ditto
bkr job-watch 24470 && bkr job-watch j:24470

I hope it explains my idea better.

Comment 4 Marian Csontos 2011-06-03 18:38:52 UTC

*** Bug 710518 has been marked as a duplicate of this bug. ***

Comment 5 Bill Peck 2011-06-03 18:48:47 UTC

(In reply to comment #2)
> In case of watchdog-extend prepending anything would be just useless: there are
> watchdogs (WDs) for tasks only. No WDS for recipes or recipe-sets.
> 
> However, I agree it might accept "T:" prefix and reject other prefixes.
> 
> Anyway +1 for the idea of commands using default prefix if missing while
> required.


I think it would be useful to extend the active task of a recipe.  so watchdog-extend could accept R:1234.


in hindsight I wish we had used unique id's across jobs, Recipesets, recipes and tasks.  Then it wouldn't have mattered.

Comment 6 Dan Callaghan 2012-08-22 23:36:53 UTC

This has already been fixed. Our --help and man pages are consistent and explanatory, and all the bkr client commands check the format of taskspec arguments before talking to the server and give a good error message.

*** This bug has been marked as a duplicate of bug 595512 ***