Bug 988276 - The original job XML is changed after submit a group job for other people
The original job XML is changed after submit a group job for other people
Status: NEW
Product: Beaker
Classification: Community
Component: scheduler (Show other bugs)
0.13
Unspecified Unspecified
medium Severity high (vote)
: ---
: ---
Assigned To: beaker-dev-list
tools-bugs
: Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-25 04:51 EDT by xjia
Modified: 2016-05-26 09:25 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-25 22:52:19 EDT
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 xjia 2013-07-25 04:51:40 EDT
Description of problem:
When I want to submit a group job userA, I will add "user=userA group=admin" in the job.xml. After submit this job, I want to clone this job. And "user=userA" is missing. Beaker should not change the origin job xml.

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

How reproducible:
Always

Steps to Reproduce:
1. submit a group job for other people
2. clone this job

Actual results:
"user=userA" is not in job.xml

Expected results:
"user=userA" should be in job.xml

Additional info:
The origin job xml should not be changed by beaker.
Comment 2 Raymond Mancy 2013-07-25 22:45:13 EDT
I think this actually qualifies as a bug against 960302
Comment 3 Nick Coghlan 2013-07-25 22:52:19 EDT
The default assumption is that jobs are cloned for submission by the user doing the cloning, so "Owner" is not one of the cloned properties.

Nominating a separate owner for a job is a property of the act of submitting a job, not a persistent property of the job itself.
Comment 4 xjia 2013-07-28 22:30:05 EDT
(In reply to Nick Coghlan from comment #3)
Point 1: If the owner add himself in the delegate list, then submit a group job for himself. Owner and delegate user is the same, but the original xml is still changed.

Point 2: If I was a customer, it's not a good interactive to change the original xml. For my point of view, the xml is user's input.

So I think this is a bug. Assign back this bug.
Comment 5 Nick Coghlan 2013-07-29 02:30:06 EDT
The problem is that the job attributes are more about a particular job *run* and less an inherent property of the job itself. As dcallagh noted on IRC, it may have been better if those attributes had all been passed as separate settings rather than being embedded in the XML, precisely to avoid this ambiguity on what it means to clone a job.

However, given the precedent set by the existing "group", "retention_tag" and "product" attributes, I'm willing to concede that preserving the "user" attribute is the right thing to do.

I don't consider it a blocker for 0.14, but we should address it for 0.15.
Comment 6 Nick Coghlan 2013-07-29 02:52:49 EDT
Current job attributes in the XML:

- user (sets the job owner to someone other than the submitter)
- group (sets group access for the job, job owner must be a member of that group)
- retention_tag (preserves the retention tag of the job as it currently exists, not as it was originally submitted)
- product (preserves the product of the job as it currently exists, not as it was originally submitted)

The latter 3 are all duplicated when cloning, the "user" setting currently is not.

Preserving all these is likely the right thing to do when a submitter clones and resubmits their own job.

Preserving retention_tag and product is likely wrong if they have been modified since the original submission.

Preserving user and group is likely wrong if the user doing the cloning isn't the original submitter.

If we nominate "clone and resubmit by original submitter" as the guiding use case for deciding the default behaviour of job cloning (with other use cases potentially requiring the deletion of unwanted attributes), then it makes sense to copy user as well.
Comment 7 Raymond Mancy 2013-07-29 07:45:57 EDT
(In reply to Nick Coghlan from comment #5)
> The problem is that the job attributes are more about a particular job *run*
> and less an inherent property of the job itself. As dcallagh noted on IRC,
> it may have been better if those attributes had all been passed as separate
> settings rather than being embedded in the XML, precisely to avoid this
> ambiguity on what it means to clone a job.
> 

So does that make it such that anything that is not 'inherent' to the job is no longer passed in XML? How do we decide what that is? 

> However, given the precedent set by the existing "group", "retention_tag"
> and "product" attributes, I'm willing to concede that preserving the "user"
> attribute is the right thing to do.
> 
> I don't consider it a blocker for 0.14, but we should address it for 0.15.
Comment 8 Raymond Mancy 2013-07-29 07:53:15 EDT
(In reply to Nick Coghlan from comment #6)
> Current job attributes in the XML:
> 
> - user (sets the job owner to someone other than the submitter)
> - group (sets group access for the job, job owner must be a member of that
> group)
> - retention_tag (preserves the retention tag of the job as it currently
> exists, not as it was originally submitted)
> - product (preserves the product of the job as it currently exists, not as
> it was originally submitted)
> 
> The latter 3 are all duplicated when cloning, the "user" setting currently
> is not.
> 
> Preserving all these is likely the right thing to do when a submitter clones
> and resubmits their own job.
> 
> Preserving retention_tag and product is likely wrong if they have been
> modified since the original submission.
> 

I think this is all a bit of a grey area and different people perhaps expect different things.

IMHO, if someone clicks on clone, they should expect to get a copy of that job as it is when they click on the clone button. That would be consistent and reasonably expected. I think what would be less expected is if someone (especially not the original submitter) came along and clicked on clone and got a job that was quite different from the one he thought he was cloning (i.e different retention tag, product, priority, cc, whiteboard etc....we would be preserving the original setting for all of these changeable fields right?)

Although we have open bugs about properties of jobs changing between submission and cloning, and the changed properties being part of the cloned job (i.e priority), and those bugs also seem valid.





> Preserving user and group is likely wrong if the user doing the cloning
> isn't the original submitter.
> 
> If we nominate "clone and resubmit by original submitter" as the guiding use
> case for deciding the default behaviour of job cloning (with other use cases
> potentially requiring the deletion of unwanted attributes), then it makes
> sense to copy user as well.
Comment 9 wangjing 2013-07-29 23:39:17 EDT
when I submit a job1 on behalf of user1, then job1 will be displayed on my job page, but the owner is user1, there is not any item of the job1 could indicate the relationship with me so that I could make sure the reason why it is on my job page, if the attribute 'user="user1"' could remain in the xml, then the xml could indecate that by cloning the job1.

also I could note it in whiteboard, but whiteboard could be changed by others sometimes, so I don't think it's an official way to indicate the relation between job1 and me.

or we could design a better way, then I could add another RFE bug.
thanks!
Comment 10 Nick Coghlan 2013-07-30 03:59:58 EDT
The lack of indication in the UI of who submitted a job is a different problem - the submitter ID should be displayed on the job details page. That's definitely a separate RFE, though.

On the "My Jobs" page, the *only* way for a job to appear with an owner other than yourself is if you submitted it on their behalf. (There may be a docs bug in that - I'm not sure we mention the possibility in the user guide. If the submitter ID was shown on the job details page, I expect that would be clear enough)

The reason I think cloning is murky for retention tags is that things like "audit" may be special - just because the results of the *previous* run are being kept around for auditing doesn't mean that the results of the *cloned* run should be kept.

Basically, I think there are four fields where it is somewhat dubious to keep them the same by default when cloning a job:

- user (the person submitting the cloned job may not be a submission delegate of that user)
- group (the person submitting the cloned job may not be a member of that group)
- priority (the priority should be the default priority)
- retention_tag (the default retention tag should be used)

*However*, and this is the important bit, I think the *precedent* that has been established is for them to be copied, even if doing so is a little dubious. Changing that for the three fields fields that are currently copied would risk breaking existing automation tools.

A potential third alternative might be to retain all these fields when a job is cloned by the original submitter or the job owner, but reset them to their defaults when a job is cloned by someone else.
Comment 14 Roman Joost 2015-11-11 01:24:46 EST
Hi,

I'd

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