Opened 11 years ago

Closed 10 years ago

#806 closed defect (fixed)

IZ3269: "denied: change consumable resource request" for virtual_free on 'running job' even though job is 'qw'

Reported by: mhanby Owned by: Dave Love <…>
Priority: normal Milestone:
Component: sge Version: 6.2u5
Severity: minor Keywords: scheduling


[Imported from gridengine issuezilla]

        Issue #:      3269             Platform:     All      Reporter: mhanby (mhanby)
       Component:     gridengine          OS:        All
     Subcomponent:    scheduling       Version:      6.2u5       CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    andreas (andreas)
      QA Contact:     andreas
       * Summary:     "denied: change consumable resource request" for virtual_free on 'running job' even though job is 'qw'
   Status whiteboard:

     Issue 3269 blocks:
   Votes for issue 3269:

   Opened: Wed Jun 9 08:37:00 -0700 2010 


I'm running GE 6.2u5 on CentOS 5.3 x86_64 (sgemaster server and clients).

If I alter the mem_free or virtual_free of a job in 'qw' status, I'll get the following error followed by the successful completion of the

$ qalter -l h_rt=1200,s_rt=900,virtual_free=1.8G 1412537
denied: can't change consumable resource request "virtual_free" of running job
modified hard resource list of job 1412537

Prior to running qalter, the jobs resource request looked like:
hard resource_list:         h_rt=1200,s_rt=900,virtual_free=1.9G

After the alter it shows that the virtual_free did, in fact, get altered, despite the error
hard resource_list:         h_rt=1200,s_rt=900,virtual_free=1.8G

This isn't a show stopper, but it has generated several trouble tickets from my users who are confused by it.


   ------- Additional comments from reuti Wed Jun 9 08:46:47 -0700 2010 -------
There are of cause two cases to distinguish:

state qw: the lines "denied: ..." shouldn't show up at all

state r: the output could be rephrased to make clear, that it won't apply to the already running job, but will be honored in case the job
gets rescheduled

   ------- Additional comments from mhanby Wed Jun 9 08:57:21 -0700 2010 -------
Also, in the case of an array job, the message should be clear that the changes again won't apply to the running tasks (unless they are
rescheduled) but will apply to the queued tasks.

Change History (2)

comment:1 Changed 10 years ago by dlove

  • Severity set to minor

The change just isn't made, so can't take effect when the job is rescheduled.
That looks like an RFE (#1352); see the comment at the call to is_changes_consumables in master/sge_job_qmaster.c(mod_job_attributes).

comment:2 Changed 10 years ago by Dave Love <…>

  • Owner set to Dave Love <…>
  • Resolution set to fixed
  • Status changed from new to closed

In [4017/sge]:

(The changeset message doesn't reference this ticket)

Note: See TracTickets for help on using tickets.