Bug 838623

Summary: Jobs submitted by different users using the same submission name end up grouped in a single submission owned by the first user
Product: Red Hat Enterprise MRG Reporter: Trevor McKay <tmckay>
Component: Release_NotesAssignee: Tomas Capek <tcapek>
Status: CLOSED CURRENTRELEASE QA Contact: ecs-bugs
Severity: medium Docs Contact:
Priority: medium    
Version: 2.1.2CC: dryan, iboverma, matt, pmackinn, sgraf
Target Milestone: 2.2Keywords: Documentation
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Cause When a job is submitted from Cumin, the "description" value is used to look up submission objects in MRG Grid. If no submission object exists with that submission description, a new submission object will be created that is owned by the submitting user. If a submission object already exists with that description, the new job will become part of the existing submission. However, the existing submission object may be owned by a different user. Submissions in Cumin are sorted by description and filtered by owner in the "Grid User" view. The submission list under "Grid User->Submissions" will only show submission objects owned by the logged in user. Consequence If a user submits a job with a description that matches an existing submission object owned by another user, the user will not be able to see their new submission in the "Grid User" view in Cumin. Workaround Users may adopt a convention to help avoid submission description duplication. For example, users my add "_username" to the end of all description values when submitting to create unique identifiers. Alternatively, the "Administrator" view in Cumin may be used since it does not suffer from this problem (all submissions are visible regardless of owner). This is only practical if role enforcement is disabled or the 'admin' role is granted to large number of users (effectively disabling role enforcement). Result A suitable convention for description values based on username should eliminate most if not all cases of description duplication. Disabling role enforcement solves the problem if the 'Administrator' views are used, but it removes the advantages of role enforcement. All users will have administrator privileges and the list of submissions will not be filtered to the logged in user.
Story Points: ---
Clone Of: 838619 Environment:
Last Closed: 2012-09-20 01:01:42 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 838619    
Bug Blocks:    

Description Trevor McKay 2012-07-09 15:52:41 UTC
This will be a known issue until it is repaired.  Statement of the problem and a work around in the Technical notes.

+++ This bug was initially created as a clone of Bug #838619 +++

Description of problem:

If multiple users submit jobs through QMF or Aviary and use the same submission name, the result will be a single submission that groups jobs owned by multiple users.  However, the submission will be owned by the first user to submit under that name.

(Submissions created with condor_submit will not have this issue when default submission names are used because the id should be unique.  However, a job file that sets "+Submission = name" explicitly can also suffer a collision.)

Cumin screens submissions by owner in the "Grid user" view.  This means that the submission will be visible to the user that owns the submission, but to no others.  The submission owner will see all jobs in the submission, including jobs they do not own -- conversely, the other users will not be able to see the submission at all.

In general, any tool that screens submissions by owner will have this problem if there is a collision in submission names.

This is not a regression, however with the addition of role enforcement in Cumin this will become a more visible problem.

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

cumin-0.1.5192-4 (and probably all versions of Cumin since the creation of submissions)

How reproducible:

100%

Steps to Reproduce:
1. Create a cumin/condor installation with multiple cumin users.
2. Log in as one user, and sumbit a job through Cumin with a submission description of "cat"
3. Log in as the second user and submit another job with a submission description of "cat"
4. Look at the submissions visible under the "Grid user" view while logged in as each user.
  
Actual results:

The first  user will be able to see the "cat" submission, including both jobs.
The second user will not be able to see the "cat" submission at all.

Expected results:

Both users should be able to see the "cat" submission.  Additionally, each user should only see the jobs within the submission that they actually own.

Additional info:

This is most likely not just a Cumin issue.  Making this work as expected may require changes on the condor side dealing with ownership semantics of submissions or some kind of a multi-part-key naming convention for submissions.

Comment 1 Trevor McKay 2012-07-09 16:23:46 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause
  When a job is submitted from Cumin, the "description" value is used to look up submission objects in MRG Grid.  If no submission object exists with that submission description, a new submission object will be created that is owned by the submitting user.

  If a submission object already exists with that description, the new job will become part of the existing submission.  However, the existing submission object may be owned by a different user.

    Submissions in Cumin are sorted by description and filtered by owner in the "Grid User" view.  The submission list under "Grid User->Submissions" will only show submission objects owned by the logged in user.

Consequence
    If a user submits a job with a description that matches an existing submission object owned by another user, the user will not be able to see their new submission in the "Grid User" view in Cumin.

Workaround
  Users may adopt a convention to help avoid submission description duplication.  For example, users my add "_username" to the end of all description values when submitting to create unique identifiers.

   Alternatively, the "Administrator" view in Cumin may be used since it does not suffer from this problem (all submissions are visible regardless of owner). This is only practical if role enforcement is disabled or the 'admin' role is granted to large number of users (effectively disabling role enforcement).

Result
    A suitable convention for description values based on username should eliminate most if not all cases of description duplication.

    Disabling role enforcement solves the problem if the 'Administrator' views are used, but it removes the advantages of role enforcement.  All users will have administrator privileges and the list of submissions will not be filtered to the logged in user.