Bug 1298480 - bkr job-submit --combine: the attr 'group' is dropped (WAS: attr 'user' is dropped)
Summary: bkr job-submit --combine: the attr 'group' is dropped (WAS: attr 'user' is dr...
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Beaker
Classification: Retired
Component: command line
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: future_maint
Assignee: Renan Rodrigo Barbosa
QA Contact: tools-bugs
URL:
Whiteboard: Triaged
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-01-14 08:56 UTC by Chunyu Hu
Modified: 2020-03-16 10:43 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-16 10:43:32 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Beaker Project Gerrit 6552 0 None ABANDONED Support --job-group in job-clone and job-submit 2020-03-16 10:42:53 UTC

Description Chunyu Hu 2016-01-14 08:56:00 UTC
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 06:48:56 UTC
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 06:51:35 UTC
(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-10 00:31:11 UTC
(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.

Comment 4 Tomas Klohna 🔧 2019-05-20 15:39:30 UTC
The support for `user` attribute has been added one month before this bug was submitted, so not sure if it just wasn't released.
Anyway, changed the title because support for `group` attribute is still missing when combining and there is no overwrite parameter as --job-owner is.

Comment 5 Tomas Klohna 🔧 2019-05-20 16:02:55 UTC
Patch also includes support for `--job-group` in both job-submit and job-clone and fixes issue in question.


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