Bug 621977
| Summary: | Appendix B Comments | ||
|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Robert Rati <rrati> |
| Component: | Grid_User_Guide | Assignee: | Lana Brindley <lbrindle> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Jeff Needle <jneedle> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | Development | CC: | mhideo |
| Target Milestone: | 1.3 | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Robert Rati
2010-08-06 16:47:01 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 (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. (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 |