Bug 1298480 - bkr job-submit --combine: the attr 'user' is dropped
bkr job-submit --combine: the attr 'user' is dropped
Status: NEW
Product: Beaker
Classification: Community
Component: command line (Show other bugs)
21
Unspecified Unspecified
unspecified Severity high (vote)
: future_maint
: ---
Assigned To: beaker-dev-list
tools-bugs
Triaged
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-14 03:56 EST by Chunyu Hu
Modified: 2016-04-26 04:46 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chunyu Hu 2016-01-14 03:56:00 EST
Description of problem:

bkr job-submit --combine doesn't care the user attr of the job tag.When Qe needs to let jenkins help to submits tests and hope the guy can put the job to 'my jobs' of the qe's beaker page, this will make it impossible since missing the attr.

Version-Release number of selected component (if applicable):

beaker-client-21.2-1.el7sed.noarch

How reproducible:

%100

Steps to Reproduce:

bkr job-submit --combine --dryrun --xml a.xml b.xml

a.xml is like:
<job retention_tag="Scratch" user="chuhu">

b.xml is same:
<job retention_tag="Scratch" user="chuhu">

Actual results:

the generated xml loses the user="chuhu" attribute.

Expected results:

the generated xml should contain the "chuhu" attrribute.

Additional info:
a.xml

<job retention_tag="Scratch" user="chuhu">
    <whiteboard>kernel-2.6.18-128.21.1.el5 KernelTier1</whiteboard>
    <recipeSet>
        <recipe ks_meta="method=nfs" whiteboard="2.6.18-128.21.1.el5">
            <distroRequires>
                <and>
                    <distro_name op="=" value="RHEL5-Server-U3"/>
                    <distro_method op="=" value="nfs"/>
                    <distro_arch op="=" value="i386"/>
                </and>
            </distroRequires>
            <hostRequires>
                <and>
                    <key_value key="CPUVENDOR" op="=" value="GenuineIntel"/>
                    <arch op="!=" value="x86_64"/>
                    <cpu_count op="=" value="1"/>
                    <hypervisor op="=" value=""/>
                </and>
            </hostRequires>
            <repos/>
            <partitions/>
            <task name="/distribution/install" role="STANDALONE">
                <params/>
            </task>
            <task name="/kernel/syscalls/scrashme/multiple" role="STANDALONE">
                <params/>
            </task>
        </recipe>
    </recipeSet>
</job>

b.xml:
<job retention_tag="Scratch" user="shdeng">
    <whiteboard>kernel-2.6.18-128.21.1.el5 KernelTier1</whiteboard>
    <recipeSet>
        <recipe ks_meta="method=nfs" whiteboard="2.6.18-128.21.1.el5 debug">
            <distroRequires>
                <and>
                    <distro_name op="=" value="RHEL5-Server-U3"/>
                    <distro_method op="=" value="nfs"/>
                    <distro_arch op="=" value="s390x"/>
                </and>
            </distroRequires>
            <hostRequires>
                <and/>
            </hostRequires>
            <repos/>
            <partitions/>
            <task name="/distribution/install" role="STANDALONE">
                <params/>
            </task>
            <task name="/kernel/syscalls/scrashme/multiple" role="STANDALONE">
                <params/>
            </task>
        </recipe>
    </recipeSet>
</job>

the generated c.xml:

<job retention_tag="Scratch"><whiteboard>kernel-2.6.18-128.21.1.el5 KernelTier1</whiteboard><recipeSet>
        <recipe ks_meta="method=nfs" whiteboard="2.6.18-128.21.1.el5">
            <distroRequires>
                <and>
                    <distro_name op="=" value="RHEL5-Server-U3"/>
                    <distro_method op="=" value="nfs"/>
                    <distro_arch op="=" value="i386"/>
                </and>
            </distroRequires>
            <hostRequires>
                <and>
                    <key_value key="CPUVENDOR" op="=" value="GenuineIntel"/>
                    <arch op="!=" value="x86_64"/>
                    <cpu_count op="=" value="1"/>
                    <hypervisor op="=" value=""/>
                </and>
            </hostRequires>
            <repos/>
            <partitions/>
            <task name="/distribution/install" role="STANDALONE">
                <params/>
            </task>
            <task name="/kernel/syscalls/scrashme/multiple" role="STANDALONE">
                <params/>
            </task>
        </recipe>
      </recipeSet><recipeSet>
        <recipe ks_meta="method=nfs" whiteboard="2.6.18-128.21.1.el5 debug">
            <distroRequires>
                <and>
                    <distro_name op="=" value="RHEL5-Server-U3"/>
                    <distro_method op="=" value="nfs"/>
                    <distro_arch op="=" value="s390x"/>
                </and>
            </distroRequires>
            <hostRequires>
                <and/>
            </hostRequires>
            <repos/>
            <partitions/>
            <task name="/distribution/install" role="STANDALONE">
                <params/>
            </task>
            <task name="/kernel/syscalls/scrashme/multiple" role="STANDALONE">
                <params/>
            </task>
        </recipe>
    </recipeSet></job>
Comment 1 Dan Callaghan 2016-01-18 01:48:56 EST
I guess this applies to group="" as well, which is also discarded by the --combine option.

What is the expected behaviour if the jobs being combined have different values for user="" attribute? For example the first job has no user="" but the second job has user="dcallagh"? Should the job be submitted for dcallagh or not?

Maybe a better solution is to add an option to bkr job-submit to specify the job owner (overriding the user="" attribute given in the XML)?

    bkr job-submit --owner chuhu --combine a.xml b.xml c.xml
Comment 2 Chunyu Hu 2016-01-18 01:51:35 EST
(In reply to Dan Callaghan from comment #1)
> I guess this applies to group="" as well, which is also discarded by the
> --combine option.
> 
> What is the expected behaviour if the jobs being combined have different
> values for user="" attribute? For example the first job has no user="" but
> the second job has user="dcallagh"? Should the job be submitted for dcallagh
> or not?
> 
> Maybe a better solution is to add an option to bkr job-submit to specify the
> job owner (overriding the user="" attribute given in the XML)?
> 
>     bkr job-submit --owner chuhu --combine a.xml b.xml c.xml

That's a cool idea, this is really a good feature needed by us.
Comment 3 matt jia 2016-03-09 19:31:11 EST
(In reply to Dan Callaghan from comment #1)
> I guess this applies to group="" as well, which is also discarded by the
> --combine option.
> 
> What is the expected behaviour if the jobs being combined have different
> values for user="" attribute? For example the first job has no user="" but
> the second job has user="dcallagh"? Should the job be submitted for dcallagh
> or not?
> 

That makes sense to me. If no --job-owner given, we shoul use user="" on the second job for the job owner.

> Maybe a better solution is to add an option to bkr job-submit to specify the
> job owner (overriding the user="" attribute given in the XML)?
> 
>     bkr job-submit --owner chuhu --combine a.xml b.xml c.xml

We now have --job-owner for this.

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