-
Notifications
You must be signed in to change notification settings - Fork 0
/
swift.conf
239 lines (196 loc) · 7.14 KB
/
swift.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
#
# The host name of the submit machine is used by GRAM as a callback
# address to report the status of submitted jobs. In general, Swift
# can automatically detect the host name of the local machine.
# However, if the machine host name is improperly configured or if
# it does not represent a valid DNS entry, certain services (such as
# GRAM) will not be able to send job status notifications back to
# the client. The value of this property can be an IP address.
#
# Format:
# hostName=string
#
#hostName=localhost
#
# A TCP port range can be specified to restrict the ports on which GRAM
# callback services are started. This is likely needed if your submit
# host is behind a firewall, in which case the firewall should be
# configured to allow incoming connections on ports in the range.
#
# Format:
# tcp.port.range=start,end
#
TCPPortRange="50000, 50100"
#
# false - means an error will be immediately reported and cause the
# workflow to abort. At this time remote jobs that are already
# running will not be canceled
# true - means that Swift will try to do as much work as possible and
# report all errors encountered at the end. However, "errors"
# here only applies to job execution errors. Certain errors
# that are related to the Swift implementation (should such
# errors occur) will still be reported eagerly.
#
# Default: false
#
lazyErrors=true
#
# Enables tracing of procedure invocations, assignments,
# iteration constructs, as well as certain dataflow events
# such as data intialization and waiting. This is done at
# a slight decrease in performance. Traces will be available
# in the log file.
#
tracingEnabled=false
#
# Indicates when wrapper logs should be fetched from the remote site:
# true - always transfer wrapper logs
# false - only transfer wrapper logs if the job fails
#
# Default: false
#
alwaysTransferWrapperLog=true
###########################################################################
# Throttling options #
###########################################################################
#
# For the throttling parameters, valid values are either a positive integer
# or "off" (without the quotes).
#
#
# Limits the number of concurrent submissions for a workflow instance. This
# throttle only limits the number of concurrent tasks (jobs) that are being
# sent to sites, not the total number of concurrent jobs that can be run.
# The submission stage in GRAM is one of the most CPU expensive stages (due
# mostly to the mutual authentication and delegation). Having too many
# concurrent submissions can overload either or both the submit host CPU
# and the remote host/head node causing degraded performance.
#
# Default: 4
#
jobSubmitThrottle=8
#jobSubmitThrottle=off
#
# Limits the number of concurrent submissions for any of the sites Swift will
# try to send jobs to. In other words it guarantees that no more than the
# value of this throttle jobs sent to any site will be concurrently in a state
# of being submitted.
#
# Default: 2
#
hostJobSubmitThrottle=8
#hostJobSubmitThrottle=off
#
# Limits the total number of concurrent file transfers that can happen at any
# given time. File transfers consume bandwidth. Too many concurrent transfers
# can cause the network to be overloaded preventing various other signalling
# traffic from flowing properly.
#
# Default: 4
#
fileTransfersThrottle=4
#fileTransfersThrottle=off
# Limits the total number of concurrent file operations that can happen at any
# given time. File operations (like transfers) require an exclusive connection
# to a site. These connections can be expensive to establish. A large number
# of concurrent file operations may cause Swift to attempt to establish many
# such expensive connections to various sites. Limiting the number of concurrent
# file operations causes Swift to use a small number of cached connections and
# achieve better overall performance.
#
# Default: 8
#
fileOperationsThrottle=8
#fileOperationsThrottle=off
# Indicates whether the working directory on the remote site should be
# left intact even when the workflow completes successfully. This can be
# used to inspect the site working directory for debugging purposes.
#
# Default: false
#
keepSiteDir=false
# number of time a job will be retried if it fails (giving a maximum of
# 1 + execution.retries attempts at execution)
#
executionRetries=0
# Enables/disables replication. Replication is used to deal with jobs sitting
# in batch queues for abnormally large amounts of time. If replication is enabled
# and certain conditions are met, Swift creates and submits replicas of jobs, and
# allows multiple instances of a job to compete.
#
replicationEnabled=false
# If replication is enabled, this value specifies the minimum time, in seconds,
# a job needs to be queued in a batch queue in order to be considered for
# replication
#
replicationMinQueueTime=60
# The maximum number of replicas that Swift should attempt.
replicationLimit=3
# Controls how Swift will communicate the result code of running user programs
# from workers to the submit side. In files mode, a file
# indicating success or failure will be created on the site shared filesystem.
# In provider mode, the execution provider job status will
# be used. Notably, GRAM2 does not return job statuses correctly, and so
# provider mode will not work with GRAM2. With other
# providers, it can be used to reduce the amount of filesystem access compared
# to files mode.
#
# statusMode=files
# Controls how swift will supply parameters to the remote wrapper script.
# 'args' mode will pass parameters on the command line
# 'files' mode will pass parameters through an additional input file
#
# valid values: args, files
# Default: files
#
# wrapperParameterMode=args
# Determines if Swift remote wrappers will be executed by specifying an
# absolute path, or a path relative to the job initial working directory
#
# valid values: absolute, relative
# wrapperInvocationMode=absolute
#
# Limits the number of concurrent iterations that each foreach statement
# can have at one time. This conserves memory for swift programs that
# have large numbers of iterations (which would otherwise all be executed
# in parallel).
#
# Default: 16384
#
maxForeachThreads=16384
# controls whether the log file will contain provenance information
# enabling this will increase the size of log files, sometimes
# significantly.
logProvenance=false
# The URL prefix used to access local files in wrapper
# staging mode. Full URLs are created by concatenating:
# * the value of this property
# * the current swift work directory (as an absolute path)
# * the file in question (relative to the current work directory)
#
#wrapperStagingLocalServer=file://
# Files mapped by the concurrent mapper (i.e. when you don't
# explicitly specify a mapper) are deleted when they are not
# in use any more. This property can be used to prevent
# files mapped by the concurrent mapper from being deleted.
#
# Format:
# fileGCEnabled=(true|false)
#
# Default: true
#
site.local {
execution {
type: local
}
filesystem {
type: local
}
workDirectory: "swiftwork"
app.ALL {
executable: "*"
}
maxParallelTasks: 8
initialParallelTasks: 8
}
sites: [local]