Bug 621977 - Appendix B Comments
Summary: Appendix B Comments
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: Grid_User_Guide (Show other bugs)
(Show other bugs)
Version: Development
Hardware: All Linux
low
medium
Target Milestone: 1.3
: ---
Assignee: Lana Brindley
QA Contact: Jeff Needle
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-06 16:47 UTC by Robert Rati
Modified: 2013-10-23 23:17 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-10-14 20:16:56 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Robert Rati 2010-08-06 16:47:01 UTC
Description of problem:
B.2. Job status codes - This section seems missing explanation and/or the formatting is messed up.  I recognize the data and what it means, but there's no context to help the reader figure out what it all means.

B.3. Job notification codes - I think this section needs to have its formatting improved.

B.4. Shadow exit status codes - Same formatting issues as above.

Remove  JOB_NOT_CKPTED - We don't support Standard Universe.  Also remove mention in JOB_SHOULD_REQUEUE

B.5. Job hold reason codes - Same formatting issues

GlobusGramError - Remove.  We don't support globus


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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Lana Brindley 2010-08-24 22:03:46 UTC
(In reply to comment #0)
> Description of problem:
> B.2. Job status codes - This section seems missing explanation and/or the
> formatting is messed up.  I recognize the data and what it means, but there's
> no context to help the reader figure out what it all means.

This would be because I had no source information to work from. If you can provide some further text around this, then I'll quite happily put it in there.

> 
> B.3. Job notification codes - I think this section needs to have its formatting
> improved.
> 
> B.4. Shadow exit status codes - Same formatting issues as above.

This section is done as a series of variable lists, the same as the other appendix. I understand that with such short <term> entries, it looks a little odd, though. How would you prefer to handle it?

> 
> Remove  JOB_NOT_CKPTED - We don't support Standard Universe.

Done

  Also remove
> mention in JOB_SHOULD_REQUEUE

<para>
	<command>JOB_SHOULD_REQUEUE</command> is used for jobs that are not run in the standard universe, and will requeue the job to run it again
</para>


> 
> B.5. Job hold reason codes - Same formatting issues

See note above.

> 
> GlobusGramError - Remove.  We don't support globus

Done.

LKB

Comment 2 Robert Rati 2010-08-26 19:00:10 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > Description of problem:
> > B.2. Job status codes - This section seems missing explanation and/or the
> > formatting is messed up.  I recognize the data and what it means, but there's
> > no context to help the reader figure out what it all means.
> 
> This would be because I had no source information to work from. If you can
> provide some further text around this, then I'll quite happily put it in there.

We already mention and define Universes (5.1.2), I think the formatting here just needs to be cleaned up.  It all feels very disjointed.  Maybe a table instead of free-form text?  For exmaple:
5
    Vanilla universe
    Single process, non-relinked jobs 

When I read though it, 5 seems disconnected to its explanation.  Same issue with B2.  I think a table would solve the disjointedness.  

For B2, I think a 3 column table:
#     Short Description (used by tools like condor_status)     Long Description



> > 
> > B.3. Job notification codes - I think this section needs to have its formatting
> > improved.
> > 
> > B.4. Shadow exit status codes - Same formatting issues as above.
> 
> This section is done as a series of variable lists, the same as the other
> appendix. I understand that with such short <term> entries, it looks a little
> odd, though. How would you prefer to handle it?

Tables seem like a clean means to present all the information in these sections.
 
>   Also remove
> > mention in JOB_SHOULD_REQUEUE
> 
> <para>
>  <command>JOB_SHOULD_REQUEUE</command> is used for jobs that are not run in the
> standard universe, and will requeue the job to run it again
> </para>

My bad.  We don't support standard universe.  Suggest changing text to:
This exit code implies that we want the job to be put back in the job queue and run again.

Comment 3 Lana Brindley 2010-09-08 00:15:31 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > Description of problem:
> > > B.2. Job status codes - This section seems missing explanation and/or the
> > > formatting is messed up.  I recognize the data and what it means, but there's
> > > no context to help the reader figure out what it all means.
> > 
> > This would be because I had no source information to work from. If you can
> > provide some further text around this, then I'll quite happily put it in there.
> 
> We already mention and define Universes (5.1.2), I think the formatting here
> just needs to be cleaned up.  It all feels very disjointed.  Maybe a table
> instead of free-form text?  For exmaple:
> 5
>     Vanilla universe
>     Single process, non-relinked jobs 
> 
> When I read though it, 5 seems disconnected to its explanation.  Same issue
> with B2.  I think a table would solve the disjointedness.  
> 
> For B2, I think a 3 column table:
> #     Short Description (used by tools like condor_status)     Long Description
> 
> 
> 
> > > 
> > > B.3. Job notification codes - I think this section needs to have its formatting
> > > improved.
> > > 
> > > B.4. Shadow exit status codes - Same formatting issues as above.
> > 
> > This section is done as a series of variable lists, the same as the other
> > appendix. I understand that with such short <term> entries, it looks a little
> > odd, though. How would you prefer to handle it?
> 
> Tables seem like a clean means to present all the information in these
> sections.
> 

Done.

> >   Also remove
> > > mention in JOB_SHOULD_REQUEUE
> > 
> > <para>
> >  <command>JOB_SHOULD_REQUEUE</command> is used for jobs that are not run in the
> > standard universe, and will requeue the job to run it again
> > </para>
> 
> My bad.  We don't support standard universe.  Suggest changing text to:
> This exit code implies that we want the job to be put back in the job queue and
> run again.

<row>
	<entry>
		<command>107</command>
	</entry>
	<entry>
		<command>JOB_SHOULD_REQUEUE</command>
	</entry>
	<entry>
		Requeue the job to be run again
	</entry>

</row>

LKB


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