-
Notifications
You must be signed in to change notification settings - Fork 1
/
NOTES-custom-config
54 lines (41 loc) · 1.69 KB
/
NOTES-custom-config
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
This is currently just a repository for notes about the custom swift feature.
Pros:
-----
* Can use resources not supported directly by SwiftR
* Dynamic provisioning of workers
* Additional configurability
* Can handle situations beyond what snowfall can.
Cons:
-----
* Additional complexity of having to write own sites, etc file
* Less responsive: typically rely on workers to fire up after apply job is started
Use Cases:
----------
* Long-running script where we want to be able to dynamically procure workers
- don't want to be in situation where batch allocation ends and job fails
* More complex situations - e.g. running swift on a grid or multiple sites
We can either use a coaster provider, or a non-coaster provider (e.g. GRAM or condor)
Coasters Provider:
-------------------
- This should be the primary use case
- What are sensible default settings?
- What settings do users actually need to change? Is there an easier way to handle common cases than always requiring users to write a file from scratch?
- Problem: coasters seem to be released when swift work queue gets short at
end of apply job, but R could be about to release another set of jobs.
Non-Coasters Provider:
-----------------------
- Doesn't make sense to use EvalRBatchPersistent script as each job will only be run once
- This only suits long-running data crunching
How to configure
-----
system requirements:
* R needs to be on the default path on worker nodes
sites file:
* Need one or more work pools
tc data:
* Need bash for each pool
cf:
* no special settings required
Unresolved Problems:
-------------------
- Export requires shared file system currently: need to specify all input dependencies on swift command line