Bug 732331 - The job cloned by webui could submit successfully and no warning when task is not applicable for distro
Summary: The job cloned by webui could submit successfully and no warning when task is...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Beaker
Classification: Community
Component: web UI
Version: 0.6
Hardware: All
OS: Linux
medium
medium vote
Target Milestone: ---
Assignee: Raymond Mancy
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-22 02:53 UTC by yanfu,wang
Modified: 2014-12-08 01:09 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-11-01 05:14:41 UTC


Attachments (Terms of Use)

Description yanfu,wang 2011-08-22 02:53:40 UTC
Description of problem:
I write a test case just for RHEL6 and it could show me the warning if I submit job for wrong release, like below:
# bkr workflow-simple --arch=x86_64 --distro=RHEL5-Server-U7 --task=/CoreOS/nfs-utils/Regression/bz538922-rpc-mountd-cannot-be-used-solely-for-NFSv4
WARNING: task /CoreOS/nfs-utils/Regression/bz538922-rpc-mountd-cannot-be-used-solely-for-NFSv4 not applicable for distro, ignoring
You must specify a package, type or task to run

But if I clone xml of job from beaker web-ui and change the task, the job could submit successfully and no warning provide to me.

Steps to Reproduce:
1. clone job xml: https://beaker.engineering.redhat.com/jobs/clone?job_id=121882
2. change task of "/CoreOS/nfs-utils/Regression/bz532564-nfs-status-not-lsb-compliant-with-rquotad-status" to "/CoreOS/nfs-utils/Regression/bz538922-rpc-mountd-cannot-be-used-solely-for-NFSv4" which just for RHEL6 release.
3. submit
  
Actual results:
job submit successfully: https://beaker.engineering.redhat.com/jobs/122379, in fact the task don't included in xml.

Expected results:
job should failed submit like command line way.
Give warning at least.

Comment 1 Bill Peck 2011-08-22 13:20:35 UTC
I'd like to get away from beaker doing the task filtering.  Right now we filter in two places.

1 - When you run the bkr workflow-simple command it queries the scheduler for what tasks apply to that distro.  Then gives you the warning that you mentioned.

2 - Filtering at step 1 is new,  before that we filtered at submission time.  This is where the cloning comes in and it simply strips the wrong tasks without giving you a warning.

We have always planned to remove the filtering at step 2.  If you tell beaker to do something via the xml it should just do it.  This allows the filtering to be done in something else like TCMS.  


I hope this makes sense.

Comment 2 yanfu,wang 2011-08-23 02:44:02 UTC
(In reply to comment #1)
> I'd like to get away from beaker doing the task filtering.  Right now we filter
> in two places.
> 
> 1 - When you run the bkr workflow-simple command it queries the scheduler for
> what tasks apply to that distro.  Then gives you the warning that you
> mentioned.
> 
> 2 - Filtering at step 1 is new,  before that we filtered at submission time. 
> This is where the cloning comes in and it simply strips the wrong tasks without
> giving you a warning.
> 
> We have always planned to remove the filtering at step 2.  If you tell beaker
> to do something via the xml it should just do it.  This allows the filtering to
> be done in something else like TCMS.  
> 
> 
> I hope this makes sense.

Thank you for your reply.
I would like to state my feeling from QE usage.
First, I don't use TCMS and I just run job depend on beaker. If I run the job via xml and filtering do as step 2, I or others QE might mistakenly believe that the result is passed since the result return PASS, but in fact no our task included to run. This problem is likely to occur if a great mass of jobs to be scheduled.
Second, I think run by xml in web-ui should consistent with command line way from user experience at least.

My understand may wrong but still hope some improvement to be done :-)

Thank you.

Comment 3 Dan Callaghan 2012-11-01 05:14:41 UTC
As Bill mentioned in comment 1, if you give Beaker job XML to run it accepts it as is. We are trying to get Beaker out of the business of deciding what tests to run when, and managing the associated metadata. Those decisions should be made by external tools when submitting jobs to Beaker (for example workflow-tomorrow which talks to TCMS).


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