Skip to content
This repository
Browse code

Improve formatting of README.txt for github

  • Loading branch information...
commit 7acae7b9606c4cd1dc3f6b3bec81efc4f69182f3 1 parent 9551206
Ian Chesal authored

Showing 1 changed file with 20 additions and 63 deletions. Show diff stats Hide diff stats

  1. 83  README.txt
83  README.txt
@@ -12,31 +12,21 @@ SYNOPSIS
12 12
 
13 13
 DESCRIPTION
14 14
 
15  
-CondorAgent is a program that runs beside a Condor scheduler. It provides enhanced access to
16  
-scheduler-based data and scheduler actions via a HTTP-based REST interface. The interface
17  
-supports gzip compression to reduce the bandwidth needed to transfer large amounts of ClassAd
18  
-data by a factor of 10-20x making this interface suitable for querying large quantities of
19  
-data over slow network connections.
  15
+CondorAgent is a program that runs beside a Condor scheduler. It provides enhanced access to scheduler-based data and scheduler actions via a HTTP-based REST interface. The interface supports gzip compression to reduce the bandwidth needed to transfer large amounts of ClassAd data by a factor of 10-20x making this interface suitable for querying large quantities of data over slow network connections.
20 16
 
21  
-CondorAgent is deployed as either a shell script wrapped Python program (which requires Python
22  
-2.4 or greater) or as a Windows binary (which does not require a local Python installation).
  17
+CondorAgent is deployed as either a shell script wrapped Python program (which requires Python 2.4 or greater) or as a Windows binary (which does not require a local Python installation).
23 18
 
24 19
 
25 20
 
26 21
 OPTIONS
27 22
 
28  
-There are no command line options at present for this tool. All configuration and control of 
29  
-CondorAgent is done via Condor configuration settings. Please see the section CONDOR CONFIGURATION
30  
-for more information on installing and configuring CondorAgent.
  23
+There are no command line options at present for this tool. All configuration and control of CondorAgent is done via Condor configuration settings. Please see the section CONDOR CONFIGURATION for more information on installing and configuring CondorAgent.
31 24
 
32 25
 
33 26
 
34 27
 CONDOR CONFIGURATION
35 28
 
36  
-To enable the CondorAgent on a scheduler, extract the appropriate CondorAgent package into Condor's
37  
-sbin directory (or the bin directory for a Windows installation). Add the following to your local
38  
-Condor configuration file to register CondorAgent as a daemon the condor_master process on this
39  
-machine will monitor and control:
  29
+To enable the CondorAgent on a scheduler, extract the appropriate CondorAgent package into Condor's sbin directory (or the bin directory for a Windows installation). Add the following to your local Condor configuration file to register CondorAgent as a daemon the condor_master process on this machine will monitor and control:
40 30
 
41 31
 	CONDOR_AGENT = $(SBIN)/condor_agent/condor_agent
42 32
 	CONDOR_AGENT_ENVIRONMENT = "CONDOR_BIN_PATH=$(BIN)"
@@ -47,13 +37,9 @@ machine will monitor and control:
47 37
 
48 38
 If running on Windows the CONDOR_AGENT line should reference condor_agent.exe instead of condor_agent.
49 39
 
50  
-Note that the CONDOR_AGENT_SUBMIT_DIR directory can be any directory on disk into which the job files
51  
-can  be written. The above is only a suggested default location. If you do not intend to do submissions
52  
-over the REST interface with this CondorAgent installation you can omit this setting.
  40
+Note that the CONDOR_AGENT_SUBMIT_DIR directory can be any directory on disk into which the job files can  be written. The above is only a suggested default location. If you do not intend to do submissions over the REST interface with this CondorAgent installation you can omit this setting.
53 41
 
54  
-When making changes to CondorAgent configuration settings it is important to remember to reconfigure
55  
-all the Condor daemons on the machine, otherwise the CondorAgent won't see config changes made in
56  
-the files.
  42
+When making changes to CondorAgent configuration settings it is important to remember to reconfigure all the Condor daemons on the machine, otherwise the CondorAgent won't see config changes made in the files.
57 43
 
58 44
 Reconfigure this Condor installation:
59 45
 
@@ -74,56 +60,41 @@ You can verify the agent is running on this box using curl:
74 60
 
75 61
 This should return output similar to a `condor_q -l` call.
76 62
 
77  
-If you're running a CycleServer instance version 4.0.3 or earlier you will need to add some additional
78  
-Condor configuration in order for CycleServer to detect the agent's presence on this scheduling
79  
-node and being to fetch job and history information from this node using the CondorAgent after two
80  
-polling intervals have completed.
  63
+If you're running a CycleServer instance version 4.0.3 or earlier you will need to add some additional Condor configuration in order for CycleServer to detect the agent's presence on this scheduling node and being to fetch job and history information from this node using the CondorAgent after two polling intervals have completed.
81 64
 
82 65
 Add the following configuration in the case where CycleServer is in use:
83 66
 
84 67
 	CYCLE_AGENT_PORT = $(CONDOR_AGENT_PORT)
85 68
 	SCHEDD_ATTRS = CYCLE_AGENT_PORT, $(SCHEDD_ATTRS)
86 69
 
87  
-To enable access to historical job information via CondorAgent we recommend the following Condor
88  
-settings:
  70
+To enable access to historical job information via CondorAgent we recommend the following Condor settings:
89 71
 
90 72
 	HISTORY = $(SPOOL)/history
91 73
 	ENABLE_HISTORY_ROTATION = True
92 74
 	MAX_HISTORY_LOG = 4000000
93 75
 	MAX_HISTORY_ROTATIONS = 5
94 76
 
95  
-This will ensure that the history log files stay reasonable small and provide about 20-24MB of history (5 backups
96  
-plus the original). A job ClassAd is usually less than 4k, so this is over 5000 jobs.
  77
+This will ensure that the history log files stay reasonable small and provide about 20-24MB of history (5 backups plus the original). A job ClassAd is usually less than 4k, so this is over 5000 jobs.
97 78
 
98 79
 
99 80
 
100 81
 THE SUBMISSION PROXY
101 82
 
102  
-The Condor Agent instance on a machine can act as a submission proxy for Condor jobs, allowing you to perform
103  
-"remote" submissions to Condor over a REST-HTTP interface without having to rely on the Condor SOAP API or
104  
-the 'condor_submit -remote' command line submission approach. This approach provides some of the convenience
105  
-of the programmatic SOAP API to the Condor scheduler with some of the speed of the batch processing that
106  
-occurs when submitting locally using the 'condor_q' command.
  83
+The Condor Agent instance on a machine can act as a submission proxy for Condor jobs, allowing you to perform "remote" submissions to Condor over a REST-HTTP interface without having to rely on the Condor SOAP API or the 'condor_submit -remote' command line submission approach. This approach provides some of the convenience of the programmatic SOAP API to the Condor scheduler with some of the speed of the batch processing that occurs when submitting locally using the 'condor_q' command.
107 84
 
108  
-To enable proxy submissions on a scheduling machine add the following to the Condor configuration on the
109  
-machine:
  85
+To enable proxy submissions on a scheduling machine add the following to the Condor configuration on the machine:
110 86
 
111 87
   CONDOR_AGENT_SUBMIT_PROXY = True
112 88
   CONDOR_AGENT_SUBMIT_DIR = $(LOCAL_DIR)/submit
113 89
 
114  
-The submission dir is local scratch space that is used for the submission ticket and some log stubs that
115  
-Condor requires exist during the lifetime of the job. It should be on disk that's local to the system
116  
-and not remote mounted. Issues with remote mounted submission scratch space have been reported with the
117  
-beta release of this feature.
  90
+The submission dir is local scratch space that is used for the submission ticket and some log stubs that Condor requires exist during the lifetime of the job. It should be on disk that's local to the system and not remote mounted. Issues with remote mounted submission scratch space have been reported with the beta release of this feature.
118 91
 
119 92
 To turn the feature on:
120 93
 
121 94
   condor_restart -subsys CYCLE_AGENT
122 95
   condor_reconfig -full -schedd
123 96
 
124  
-If you're using CycleServer as your job submission interface it will now use the proxy submission API on
125  
-the Agent to place jobs in to any scheduler running on this machine. For information on how to access the
126  
-submission API please see THE REST API section for the /condor/submit URL.
  97
+If you're using CycleServer as your job submission interface it will now use the proxy submission API on the Agent to place jobs in to any scheduler running on this machine. For information on how to access the submission API please see THE REST API section for the /condor/submit URL.
127 98
 
128 99
 
129 100
 
@@ -132,23 +103,15 @@ THE REST API
132 103
 
133 104
 /condor/submit
134 105
 
135  
-The submission API lets you perform local-type Condor submissions using a remotely-accessing HTTP interface.
136  
-It is a much faster interface for queuing large quantities of jobs than the SOAP API that ships with
137  
-Condor as it leverages the batching semantics inherent in condor_submit and does not need to retransmit
138  
-data for every single job in a cluster as the SOAP API requires.
  106
+The submission API lets you perform local-type Condor submissions using a remotely-accessing HTTP interface. It is a much faster interface for queuing large quantities of jobs than the SOAP API that ships with Condor as it leverages the batching semantics inherent in condor_submit and does not need to retransmit data for every single job in a cluster as the SOAP API requires.
139 107
 
140  
-The interface handles POST messages. It expects the body of the post to be of type Application/Zip and the
141  
-payload to be a zip file that contains a single *.sub file to be used for the submission. The submission
142  
-is performed without any modifications to the *.sub file found in the body of the POST. It is a local
143  
-submission, so you will need to ensure that your submission file is setup accordingly.
  108
+The interface handles POST messages. It expects the body of the post to be of type Application/Zip and the payload to be a zip file that contains a single *.sub file to be used for the submission. The submission is performed without any modifications to the *.sub file found in the body of the POST. It is a local submission, so you will need to ensure that your submission file is setup accordingly.
144 109
 
145  
-The API has one option: the queue to use on the machine for the submission. This option exists to support
146  
-multi-schedd scenarios where more than one condor_schedd may be started on a machine at a time.
  110
+The API has one option: the queue to use on the machine for the submission. This option exists to support multi-schedd scenarios where more than one condor_schedd may be started on a machine at a time.
147 111
 
148 112
 Example:
149 113
 
150  
-	This example use curl (http://curl.haxx.se/) to POST a new submission to a Linux-based
151  
-	scheduler using the REST API.
  114
+	This example use curl (http://curl.haxx.se/) to POST a new submission to a Linux-based scheduler using the REST API.
152 115
 
153 116
 	We have a file on disk, submit.sub, that contains the following:
154 117
 	
@@ -171,10 +134,7 @@ Example:
171 134
 		CLUSTERID = `curl -X POST -H "Content-Type: application/zip" --data-binary \
172 135
 			@submit.zip "http://myschedd:8008/condor/submit?queue=myschedd`
173 136
 		
174  
-	On success the API returns a 200 message with the new cluster ID of the submission as the body of the
175  
-	message. In the example above this cluster ID is now stored in the environment variable	$CLUSTERID for
176  
-	future use. On failure you'll get a 500 return code from the web server and the body of	the message will
177  
-	contain failure analysis information showing you what went wrong with the submission.
  137
+	On success the API returns a 200 message with the new cluster ID of the submission as the body of the message. In the example above this cluster ID is now stored in the environment variable $CLUSTERID for future use. On failure you'll get a 500 return code from the web server and the body of the message will contain failure analysis information showing you what went wrong with the submission.
178 138
 	
179 139
 	We can query the system for information about this job now with:
180 140
 	
@@ -197,11 +157,8 @@ Copyright (C) 2007-2011, Cycle Computing, LLC.
197 157
 
198 158
 LICENSE
199 159
 
200  
-Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in
201  
-compliance with the License.  You may obtain a copy of the License at
  160
+Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.  You may obtain a copy of the License at
202 161
 
203 162
 	http://www.apache.org/licenses/LICENSE-2.0.txt
204 163
 
205  
-Unless required by applicable law or agreed to in writing, software distributed under the License is
206  
-distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
207  
-See the License for the specific language governing permissions and limitations under the License.
  164
+Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

0 notes on commit 7acae7b

Please sign in to comment.
Something went wrong with that request. Please try again.