-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathREADME.md.bak
71 lines (60 loc) · 3.09 KB
/
README.md.bak
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
# yar
-------
![alt tag](https://40.media.tumblr.com/tumblr_lopphnsL821qz874do1_500.jpg)
**Yar** is a declarative DSL for modeling process pipeline scenarios that require provisioning complex distributed systems and/or real integrations with external services in a production or production-like environment. The framework is designed around inversion of control/dependency injection, so that tests use the so-called [Hollywood principle](https://en.wikipedia.org/wiki/Hollywood_principle) (i.e., "don't call us, we'll call you") to maintain a high degree of modularity and decoupling.
The primary components that make up any model are the **profile** and the **scenario**. The source code for both is written in YAML (n.b., JSON is valid YAML). A _profile_ models a particular state, whereas a _scenario_ describes the hierarchical relationship between possible profile branches. A good analogy is vertices and edges in a directed graph. Each profile is intended to serve as a logical snapshot from where any number of other profiles can extend. A branch potentially _requires_ certain data from any given profile and _provides_ certain data that other branches can use as inputs. These inputs and outputs are designed to be similar to patches in audio synth modules, or filter pipelining in the Digital Signal Processing domain generally.
A simple profile that creates a cluster, installs a service, and runs a smoketest to verify that it's responding to requests might look like this:
```yaml
requires:
- key: REPO_HOME
description: the path to the repository where the smoketest lives
provides:
- key: MY_CLUSTER_PUBLIC_IP
description: the public ip-addr for the node where the service is running
checkpoints:
groups:
- group:
- cluster-name: my-cluster
exec: dig +short myip.opendns.com @resolver1.opendns.com
out: MY_CLUSTER_PUBLIC_IP
- group:
- description: >
A smoke test that pings the api base n times every m seconds to
verify that the service has started
exec: >
$REPO_HOME/tests/smoketests/smoketest.sh 10 2
$MY_CLUSTER_PUBLIC_IP:8080/api/
clusters:
groups:
- group:
- cluster-name: my-cluster
num-nodes: 1
products:
groups:
group:
- product: my-service
version-or-branch: some-github-branch
install-type: source
start: true
```
A scenario might look something like this:
```yaml
profile: /path/to/a/profile.yaml
next:
- profile: /path/to/another/profile.yaml
in:
REQUIRED_FOO: PROVIDED_FOO
- profile: /path/to/yet/another/profile.yaml
isolate: true
in:
REQUIRED_BAR: PROVIDED_BAR
REQUIRED_BAZ: PROVIDED_BAZ
next:
- profile: /another/profile.yaml
in:
REQUIRED_QUUX: PROVIDED_QUUX
```
### Using [leiningen](http://leiningen.org):
```bash
lein run /path/to/some/scenario.yaml
```