forked from madduck/reclass
-
Notifications
You must be signed in to change notification settings - Fork 0
/
README.Salt
144 lines (100 loc) · 5.38 KB
/
README.Salt
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
=============================================================
reclass — recursive external node classification
=============================================================
reclass is © 2007–2013 martin f. krafft <madduck@madduck.net>
and available under the terms of the Artistic Licence 2.0
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Please make sure to read the generic information in the README file first, or
alongside this document.
Quick start with Salt
~~~~~~~~~~~~~~~~~~~~~
The following steps should get you up and running quickly. You will need to
decide for yourself where to put your reclass inventory. This can be
your first base file_root (the default), or it could be /etc/reclass, or
/srv/salt. The following shall assume the latter.
Or you can also just look into ./examples/salt of your reclass checkout,
where the following steps have already been prepared.
/…/reclass refers to the location of your reclass checkout.
0. Complete the installation steps described in the section 'Installation'
in the main README file.
Alternatively, you can also tell Salt via the master config file where to
look for reclass, but then you won't be able to interact with reclass
through the command line.
1. Copy the two directories 'nodes' and 'classes' from the example
subdirectory in the reclass checkout to e.g. /srv/salt.
It's handy to symlink reclass' Salt adapter itself to that directory.
$ ln -s $(which salt-reclass) /srv/salt/states/reclass
As you can now just inspect the data right there from the command line:
$ ./reclass --top
If you don't want to do this, you can also let reclass know where to look
for the inventory with the following contents in
$HOME/reclass-config.yml:
storage_type: yaml_fs
nodes_uri: /srv/reclass/nodes
classes_uri: /srv/reclass/classes
Or you can reuse the first entry of 'file_roots' under 'base' in the Salt
master config.
Note that yaml_fs is currently the only supported storage_type, and it's
the default if you don't set it.
2. Check out your inventory by invoking
$ salt-reclass --top
which should return all the information about all defined nodes, which is
only 'localhost' in the example. This is essentially the same information
that you would keep in your top.sls file.
If you symlinked the script to your inventory base directory, use
$ ./reclass --top
3. See the pillar information for 'localhost':
$ salt-reclass --pillar localhost
4. Now add reclass to /etc/salt/master, like so:
reclass: &reclass
inventory_base_uri: /srv/salt
reclass_source_path: ~/code/reclass
master_tops:
[…]
reclass: *reclass
ext_pillar:
- reclass: *reclass
If you did not install reclass, you can either specify the source path
like above, or you can add it to PYTHONPATH before invoking the Salt
master, to ensure that Python can find it:
PYTHONPATH=/…/reclass /etc/init.d/salt-master restart
5. Provided that you have set up 'localhost' as a Salt minion, the following
commands should now return the same data as above, but processed through
salt:
$ salt localhost pillar.items # shows just the parameters
$ salt localhost state.show_top # shows only the states (applications)
Alternatively, if you don't have the Salt minion running yet:
# salt-call pillar.items # shows just the parameters
# salt-call state.show_top # shows only the states (applications)
6. You can also invoke reclass directly, which gives a slightly different
view onto the same data, i.e. before it has been adapted for Salt:
$ reclass --inventory
$ reclass --nodeinfo localhost
Integration with Salt
~~~~~~~~~~~~~~~~~~~~~
reclass hooks into Salt at two different points: master_tops and ext_pillar.
For both, Salt provides plugins. These plugins need to know where to find
reclass, so if reclass is not properly installed (but you are running it from
source), make sure to export PYTHONPATH accordingly before you start your Salt
master, or specify the path in the master configuration file, as show above.
Salt has no concept of "nodes", "applications", "parameters", and "classes".
Therefore it is necessary to explain how those correspond to Salt. Crudely,
the following mapping exists:
nodes hosts
classes - [*]
applications states
parameters pillar
[*] See Salt issue #5787 for steps into the direction of letting reclass
provide nodegroup information.
Whatever applications you define for a node will become states applicable to
a host. If those applications are added via ancestor classes, then that's
fine, but currently, Salt does not do anything with the classes ancestry.
Similarly, all parameters that are collected and merged eventually end up in
the pillar data of a specific node.
However, the pillar data of a node include all the information about classes
and applications, so you could theoretically use them to target your Salt
calls at groups of nodes defined in the reclass inventory, e.g.
salt -I __reclass__:classes:salt_minion test.ping
Unfortunately, this does not work yet, please stay tuned, and let me know
if you figure out a way. Salt issue #5787 is also of relevance.
-- martin f. krafft <madduck@madduck.net> Wed, 07 Aug 2013 16:21:04 +0200