Hide Forgot
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.
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.
(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.
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).