Custom Query (431 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (49 - 51 of 431)

Ticket Resolution Summary Owner Reporter
#362 fixed IZ2066: drmaa_run_bulk_jobs() input parameter data types must be consistent with 1.0 specification andreas
Description

[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=2066]

        Issue #:      2066             Platform:     Sun      Reporter: andreas (andreas)
       Component:     gridengine          OS:        All
     Subcomponent:    drmaa            Version:      6.0         CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    templedf (templedf)
      QA Contact:     templedf
          URL:
       * Summary:     drmaa_run_bulk_jobs() input parameter data types must be consistent with 1.0 specification
   Status whiteboard:
      Attachments:

     Issue 2066 blocks:
   Votes for issue 2066:


   Opened: Wed May 31 07:06:00 -0700 2006 
------------------------


DESCRIPTION:
The DRMAA 1.0 specification defines drmaa_run_bulk_jobs parameters as:

  start, end - unsigned integer
  incr - signed integer

in DRMAA 0.95 binding 'start' and 'end' are signed integer.
#426 fixed IZ2248: add -u <user> to scheduler category only if there is a resource quota for the user andreas
Description

[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=2248]

        Issue #:      2248             Platform:     All      Reporter: andreas (andreas)
       Component:     gridengine          OS:        All
     Subcomponent:    scheduling       Version:      6.1         CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: 6.0u1
      Assigned to:    andreas (andreas)
      QA Contact:     andreas
          URL:        http://gridengine.sunsource.net/servlets/ReadMsg?list=cvs&msgNo=8763
       * Summary:     add -u <user> to scheduler category only if there is a resource quota for the user
   Status whiteboard:
      Attachments:

     Issue 2248 blocks:
   Votes for issue 2248:


   Opened: Fri May 11 10:12:00 -0700 2007 
------------------------


DESCRIPTION:
If resource quotas are used the scheduler category string contains always "-u
<user>". This is true even in cases when there is no resource quota for the user.

E.g. with a resource quota limit such as

   limit        projects {*} to F001=1,F002=1,F003=1,F004=1,F005=1, \
   F006=1,F007=1,F008=1,F009=1,F010=1

the category field in accounting(8) contains: "-u ah114088 -l F006=1 -P
Project1". The scheduler category is central with performance optimization.
Depending on the setup it can be quite expensive in terms of dispatching time to
add "-u <user>" if not needed.

   ------- Additional comments from andreas Fri May 11 10:21:58 -0700 2007 -------
Fixed in Maintrunk.
#492 fixed IZ2507: "root" should be able to submit jobs for arbitrary users via DRMAA Dave Love <d.love@…> andreas
Description

[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=2507]

   Issue #: 2507   Platform: All   Reporter: andreas (andreas)
   Component: gridengine   OS: All
   Subcomponent: drmaa   Version: 6.1u3   CC:
   [_] james
   [_] Remove selected CCs
   Status: STARTED   Priority: P3
   Resolution:   Issue type: ENHANCEMENT
     Target milestone: Maintrunk
   Assigned to: templedf (templedf)
   QA Contact: templedf
   URL: http://gridengine.sunsource.net/servlets/BrowseList?list=dev&by=thread&from=28404
   * Summary: "root" should be able to submit jobs for arbitrary users via DRMAA
   Status whiteboard:
   Attachments:
   Date/filename:                                     Description:                                                               Submitted by:
   Thu Feb 28 16:15:00 -0700 2008: 2507.diff          Patch to implement "drmaa_submit_as_euid" based on V61_BRANCH (text/plain) andreas
   Mon May 5 05:06:00 -0700 2008: Maintrunk_2507.diff Source diff against maintrunk (RD-2008-05-05-1) (text/plain)               andreas
   Mon May 5 06:17:00 -0700 2008: MT_man2507.diff     Man page diff against Maintrunk for drmaa_attributes(3) (text/plain)       andreas
     Issue 2507 blocks:
   Votes for issue 2507:

   Opened: Thu Feb 28 16:11:00 -0700 2008 
------------------------


DESCRIPTION:
"root" should be able to submit jobs for arbitrary users via DRMAA

HOWTOFIX:
Add a "drmaa_submit_as_euid" job template attribute, that causes effective
user/group be used when drmaa_run_job()/drmaa_run_bulk_job() is being called.

   ------- Additional comments from andreas Thu Feb 28 16:15:52 -0700 2008 -------
Created an attachment (id=155)
Patch to implement "drmaa_submit_as_euid" based on V61_BRANCH

   ------- Additional comments from andreas Fri Apr 25 05:44:10 -0700 2008 -------
According a short report I received from James Vanns he tried the attached patch
and it did work.

   ------- Additional comments from andreas Mon May 5 04:33:26 -0700 2008 -------
Changed IZ-URL so that the mail thread where Dan, James, and I discussed
implementation topics can easily be accessed by anyone.

In informal discussion a number of concernes were raised against this RFE. As to
give anyone a chance to participate in the debate I summarize those amongst the
concerns that I consider as valid:

(1) How can we sure this RFE introduces no new risks in terms of security?
(2) Will this RFE work also in CSP-security mode?

   ------- Additional comments from andreas Mon May 5 05:06:20 -0700 2008 -------
Created an attachment (id=169)
Source diff against maintrunk (RD-2008-05-05-1)

   ------- Additional comments from andreas Mon May 5 06:17:39 -0700 2008 -------
Created an attachment (id=170)
Man page diff against Maintrunk for drmaa_attributes(3)

   ------- Additional comments from roland Mon May 5 06:46:25 -0700 2008 -------
I did a quick review on the patch and as it's implemented it will not work with
SGE's CSP mode. In CSP mode on qmaster side the username provided by the
certificate and the username saved in the GDI session is compared and must be
identical. This check will fail if the context was created with the certificates
of user X and the GDI request claim to come from user Y.

   ------- Additional comments from andreas Mon May 5 07:55:12 -0700 2008 -------
Specificatioon document draft now available under

http://wiki.gridengine.info/wiki/index.php/Submission_for_arbitrary_jobs_via_DRMAA

   ------- Additional comments from andreas Tue May 6 06:01:48 -0700 2008 -------
Having investigated the certificate handling in qmaster I must confirm Rolands
comments. After consultation with Andre I see three possibilities to deal with
that issue:

(1) Enhance the handling of GDI session certificates in a way that one can allow
special rights be consigned from the GDI session owner to the user in whose
procuration the GDI request was sent to qmaster. Imagination is this would
require a general enhancement of SGE certificate schema. Yet as of now there is
no real conception how this schema enhancement had to look like and it is
therefore unclear whether it could be accordingly implemented at all.

(2) Do a small code modification in qmaster where GDI session user and GDI
request user matching ist done (i.e. sge_security_verify_user() and/or
sge_security_verify_unique_identifier()) in a way that procuration is generally
allowed, but only if the GDI session user could be verified as "root" through a
 certificate at the time when the GDI session was opened.

(3) Accept the patch as it is and therefore mention in the release notes and the
drmaa_attributes(3) man page, that "drmaa_submit_as_euid" does not function as
of now. In addition a bug would be filed against "drmaa_submit_as_euid" to make
sure this feature gap is not forgotten.

In my opinion all three options could be justified.

   ------- Additional comments from andreas Thu May 8 09:00:02 -0700 2008 -------
Defered to a 6.2 follow-up version.

Had needed more closer cooperation amongst different stakeholders for getting it
into 6.2 beta.
Note: See TracQuery for help on using queries.