Bug 584030
| Summary: | Low Latency Grid Document not complete | ||
|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | William Henry <whenry> |
| Component: | Grid_User_Guide | Assignee: | Alison Young <alyoung> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Lubos Trilety <ltrilety> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1.2 | CC: | iboverma, lbrindle, ltrilety, matt, rrati |
| Target Milestone: | 2.0 | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-02-02 23:27:45 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
William Henry
2010-04-20 14:58:14 UTC
(In reply to comment #0) > Description of problem: > > Chapter 14 for the Grid user guide needs work > > Here are some notes on *needed* improvements to the documentation. (I.e. These > are not nice to haves but necessary.) > > 1. We need to provide example python and C++ examples for job submission. > Currently the user would have git the code from tests from the git repo. Also > these tests are only python (maybe that's okay for the moment) and they are > also pretty complicated because we use them to test. They are very good and I > particularly like the file_transfer.py example. Can it be simplified any more > or tidied up? This will require further information from engineering. > > 2. The code snippet supplied in the documentation should be explained. Consider > that the reader may not understand AMQP and may not understand the concepts of > headers versus body etc. Why the headers? If there is no particular reason > then explain it was just a design preference etc. This will require further information from engineering. > > 3. It's worth a short description of every line of the configuration. This will require further information from engineering. > > 4. It is unclear from the docs that the config settings are only for > execution nodes. It may be obvious to engineering but we ought to explain > how, due to the nature of the job submission through qpid, there is no > extra configuration for non-execution nodes. <orderedlist id="orde-Grid_User_Guide-Low_latency_scheduling-Installing_and_configuring_low_latency_on_submit_nodes"> <title>Installing and configuring low-latency on submit nodes</title> <listitem> <note> <para> Because of the way that &RHM; handles job submission, there is no need to configure non-execution nodes. These instructions cover installing and configuring submit nodes only. </para> </note> > > 5. As an extra it might be worth explaining that you can carve up your low-lat > pool of execute nodes into different priorities and or projects etc. This > can be done by providing different values for the queue name. So instead of > one 'grid' you could have 'grid_high' and 'grid-low'. The client program can > use the appropriate routing-key to get to the queue. Actually in the new API > the programmer can just send to the grid-high or grid-low node. (Btw I would > regard this as much out-of-the-box as the current single example. i.e. we > support this out of the box. Contact me whenry for more info on this) <para> Low-latency scheduling also allows a pool of execute nodes to be divided into different projects or priorities. This is achieved by providing different values for the name of the queue. For example, instead of one single queue named <parameter>grid</parameter>, it could be split into two queues named <parameter>grid_high</parameter> and <parameter>grid_low</parameter>. The client program would then be able to use the appropriate routing key to get to the needed queue. This can also be achieved through the API. </para> > > In summary: overdo the information and explanations. It's better to give > too much than too little. Without wanting to get deep into tech writing strategy and planning, I *almost* agree with you. It's important that we give all the information required by the user, not necessarily all the information available. It's hard to pick the wheat from the chaff, though, and it's probably better to err on the side of "lots of info, some of which might not be relevant" than "not much info at all, how do I turn the thing on?". -----8<----- The information above is incomplete. Please review the updated book on the stage (it will be available there within 24 hours), and provide further information where requested. LKB *** Bug 588796 has been marked as a duplicate of this bug. *** *** Bug 588797 has been marked as a duplicate of this bug. *** (In reply to comment #1) > (In reply to comment #0) > > > > 4. It is unclear from the docs that the config settings are only for > > execution nodes. It may be obvious to engineering but we ought to explain > > how, due to the nature of the job submission through qpid, there is no > > extra configuration for non-execution nodes. > > <orderedlist > id="orde-Grid_User_Guide-Low_latency_scheduling-Installing_and_configuring_low_latency_on_submit_nodes"> > <title>Installing and configuring low-latency on submit nodes</title> > <listitem> > <note> > <para> > Because of the way that &RHM; handles job submission, there is no need to > configure non-execution nodes. These instructions cover installing and > configuring submit nodes only. > </para> > </note> > Execution node may not be submit node and vice versa. So the sentence should be that these settings is only for execution nodes not submit nodes. What about those points where more information from developers were needed? I don't see any further comment about them only removed needinfo flag. (In reply to comment #4) > > Execution node may not be submit node and vice versa. So the sentence should be > that these settings is only for execution nodes not submit nodes. <title>Installing and configuring low-latency on execute nodes</title> <listitem> <note> <para> Because of the way that &RHM; handles job submission, there is no need to configure non-execution nodes. These instructions cover installing and configuring execute nodes only. </para> </note> > > What about those points where more information from developers were needed? I > don't see any further comment about them only removed needinfo flag. They're still outstanding. Sorry, not sure how or why the NEEDINFO flag got cleared. LKB Pushing out to 1.4. LKB Closing this bug to get it off the MRG docs radar. Please open a new bug when source documentation is available. LKB |