Petr Michalec | ad44117 | 2017-09-18 17:18:10 +0200 | [diff] [blame] | 1 | Escaping of References and Inventory Queries |
| 2 | -------------------------------------------- |
| 3 | |
| 4 | Reference and inventory queries can be escaped to produce literal strings, for example: |
| 5 | |
| 6 | .. code-block:: yaml |
| 7 | |
| 8 | parameters: |
| 9 | colour: Blue |
| 10 | unescaped: The colour is ${colour} |
| 11 | escaped: The colour is \${colour} |
| 12 | double_escaped: The colour is \\${colour} |
| 13 | |
| 14 | |
| 15 | This would produce: |
| 16 | |
| 17 | .. code-block:: yaml |
| 18 | |
| 19 | parameters: |
| 20 | colour: Blue |
| 21 | unescaped: The colour is Blue |
| 22 | escaped: The colour is ${colour} |
| 23 | double_escaped: The colour is \Blue |
| 24 | |
| 25 | |
| 26 | |
| 27 | Ignore class not found |
| 28 | ---------------------- |
| 29 | |
| 30 | At some cases (bootstrapping, development) it can be convenient to ignore some missing classes. |
| 31 | To control the feature there are two options available: |
| 32 | |
| 33 | .. code-block:: yaml |
| 34 | |
| 35 | ignore_class_notfound: False |
Petr Michalec | 1932474 | 2017-09-18 17:32:24 +0200 | [diff] [blame] | 36 | ignore_class_regexp: ['.*'] |
Petr Michalec | ad44117 | 2017-09-18 17:18:10 +0200 | [diff] [blame] | 37 | |
| 38 | If you set regexp pattern to ``service.*`` all missing classes starting 'service.' will be logged with warning, but will not |
| 39 | fail to return rendered reclass. Assuming all parameter interpolation passes. |
| 40 | |
| 41 | |
| 42 | |
| 43 | Merging Referenced Lists and Dictionaries |
| 44 | ----------------------------------------- |
| 45 | |
| 46 | Referenced lists or dicts can now be merged: |
| 47 | |
| 48 | .. code-block:: yaml |
| 49 | |
| 50 | # nodes/test.yml |
| 51 | classes: |
| 52 | - test1 |
| 53 | - test2 |
| 54 | parameters: |
| 55 | one: |
| 56 | a: 1 |
| 57 | b: 2 |
| 58 | two: |
| 59 | c: 3 |
| 60 | d: 4 |
| 61 | three: |
| 62 | e: 5 |
| 63 | |
| 64 | # classes/test1.yml |
| 65 | parameters: |
| 66 | three: ${one} |
| 67 | |
| 68 | # classes/test2.yml |
| 69 | parameters: |
| 70 | three: ${two} |
| 71 | |
| 72 | ``running reclass.py --nodeinfo node1`` then gives: |
| 73 | |
| 74 | .. code-block:: yaml |
| 75 | |
| 76 | parameters: |
| 77 | one: |
| 78 | a: 1 |
| 79 | b: 2 |
| 80 | three: |
| 81 | a: 1 |
| 82 | b: 2 |
| 83 | c: 3 |
| 84 | d: 4 |
| 85 | e: 5 |
| 86 | two: |
| 87 | c: 3 |
| 88 | d: 4 |
| 89 | |
| 90 | This first sets the parameter three to the value of parameter one (class test1) then merges parameter two into |
| 91 | parameter three (class test2) and finally merges the parameter three definition given in the node definition into |
| 92 | the final value. |
| 93 | |
| 94 | |
| 95 | |
| 96 | Nested References |
| 97 | ----------------- |
| 98 | |
| 99 | References can now be nested, for example: |
| 100 | |
| 101 | .. code-block:: yaml |
| 102 | |
| 103 | # nodes/node1.yml |
| 104 | parameters: |
| 105 | alpha: |
| 106 | one: ${beta:${alpha:two}} |
| 107 | two: a |
| 108 | beta: |
| 109 | a: 99 |
| 110 | |
| 111 | ``reclass.py --nodeinfo node1`` then gives: |
| 112 | |
| 113 | .. code-block:: yaml |
| 114 | |
| 115 | parameters: |
| 116 | alpha: |
| 117 | one: 99 |
| 118 | two: a |
| 119 | beta: |
| 120 | a: 99 |
| 121 | |
| 122 | The ``${beta:${alpha:two}}`` construct first resolves the ``${alpha:two}`` reference to the value 'a', then resolves |
| 123 | the reference ``${beta:a}`` to the value 99. |
| 124 | |
| 125 | |
| 126 | |
| 127 | Inventory Queries |
| 128 | ----------------- |
| 129 | |
| 130 | Inventory querying works using a new key type - exports to hold values which other node definitions can read using a $[] query, for example with: |
| 131 | |
| 132 | .. code-block:: yaml |
| 133 | |
| 134 | # nodes/node1.yml |
| 135 | exports: |
| 136 | test_zero: 0 |
| 137 | test_one: |
| 138 | name: ${name} |
| 139 | value: 6 |
| 140 | test_two: ${dict} |
| 141 | |
| 142 | parameters: |
| 143 | name: node1 |
| 144 | dict: |
| 145 | a: 1 |
| 146 | b: 2 |
| 147 | exp_value_test: $[ exports:test_two ] |
| 148 | exp_if_test0: $[ if exports:test_zero == 0 ] |
| 149 | exp_if_test1: $[ exports:test_one if exports:test_one:value == 7 ] |
| 150 | exp_if_test2: $[ exports:test_one if exports:test_one:name == self:name ] |
| 151 | |
| 152 | # nodes/node2.yml |
| 153 | exports: |
| 154 | test_zero: 0 |
| 155 | test_one: |
| 156 | name: ${name} |
| 157 | value: 7 |
| 158 | test_two: ${dict} |
| 159 | |
| 160 | parameters: |
| 161 | name: node2 |
| 162 | dict: |
| 163 | a: 11 |
| 164 | b: 22 |
| 165 | |
| 166 | |
| 167 | ``running reclass.py --nodeinfo node1`` gives (listing only the exports and parameters): |
| 168 | |
| 169 | .. code-block:: yaml |
| 170 | |
| 171 | exports: |
| 172 | test_one: |
| 173 | name: node1 |
| 174 | value: 6 |
| 175 | test_two: |
| 176 | a: 1 |
| 177 | b: 2 |
| 178 | parameters: |
| 179 | dict: |
| 180 | a: 1 |
| 181 | b: 2 |
| 182 | exp_if_test0: |
| 183 | - node1 |
| 184 | - node2 |
| 185 | exp_if_test1: |
| 186 | node2: |
| 187 | name: node2 |
| 188 | value: 7 |
| 189 | exp_if_test2: |
| 190 | node1: |
| 191 | name: node1 |
| 192 | value: 6 |
| 193 | exp_value_test: |
| 194 | node1: |
| 195 | a: 1 |
| 196 | b: 2 |
| 197 | node2: |
| 198 | a: 11 |
| 199 | b: 22 |
| 200 | name: node1 |
| 201 | |
| 202 | |
| 203 | Exports defined for a node can be a simple value or a reference to a parameter in the node definition. |
Petr Michalec | ab9cac3 | 2017-09-18 17:35:54 +0200 | [diff] [blame^] | 204 | The ``$[]`` inventory queries are calculated for simple value expressions, ``$[ exports:key ]``, by returning |
| 205 | a dictionary with an element (``{ node_name: key value }``) for each node which defines 'key' in the exports |
| 206 | section. For tests with a preceeding value, ``$[ exports:key if exports:test_key == test_value ]``, the |
| 207 | element (``{ node_name: key value }``) is only added to the returned dictionary if the test_key defined in |
Petr Michalec | ad44117 | 2017-09-18 17:18:10 +0200 | [diff] [blame] | 208 | the node exports section equals the test value. For tests without a preceeding value, |
Petr Michalec | ab9cac3 | 2017-09-18 17:35:54 +0200 | [diff] [blame^] | 209 | ``$[ if exports:test_key == test_value ]``, a list of nodes which pass the test is returned. For either test |
Petr Michalec | ad44117 | 2017-09-18 17:18:10 +0200 | [diff] [blame] | 210 | form the test value can either be a simple value or a node parameter. And as well as an equality test |
Petr Michalec | ab9cac3 | 2017-09-18 17:35:54 +0200 | [diff] [blame^] | 211 | a not equals test (``!=``) can also be used. |
Petr Michalec | ad44117 | 2017-09-18 17:18:10 +0200 | [diff] [blame] | 212 | |
| 213 | |
| 214 | **Inventory query options** |
| 215 | |
| 216 | By default inventory queries only look at nodes in the same environment as the querying node. This can be |
| 217 | overriden using the +AllEnvs option: |
| 218 | |
Petr Michalec | ab9cac3 | 2017-09-18 17:35:54 +0200 | [diff] [blame^] | 219 | .. code-block:: yaml |
| 220 | |
Petr Michalec | ad44117 | 2017-09-18 17:18:10 +0200 | [diff] [blame] | 221 | $[ +AllEnvs exports:test ] |
| 222 | |
| 223 | Any errors in rendering the export parameters for a node will give an error for the inventory query as a whole. |
Petr Michalec | ab9cac3 | 2017-09-18 17:35:54 +0200 | [diff] [blame^] | 224 | This can be overriden using the ``+IgnoreErrors`` option: |
| 225 | |
| 226 | .. code-block:: yaml |
Petr Michalec | ad44117 | 2017-09-18 17:18:10 +0200 | [diff] [blame] | 227 | |
| 228 | $[ +IgnoreErrors exports:test ] |
| 229 | |
Petr Michalec | ab9cac3 | 2017-09-18 17:35:54 +0200 | [diff] [blame^] | 230 | With the ``+IgnoreErrors`` option nodes which generate an error evaluating ``exports:test`` will be ignored. |
Petr Michalec | ad44117 | 2017-09-18 17:18:10 +0200 | [diff] [blame] | 231 | |
| 232 | Inventory query options can be combined: |
| 233 | |
Petr Michalec | ab9cac3 | 2017-09-18 17:35:54 +0200 | [diff] [blame^] | 234 | .. code-block:: yaml |
| 235 | |
Petr Michalec | ad44117 | 2017-09-18 17:18:10 +0200 | [diff] [blame] | 236 | $[ +AllEnvs +IgnoreErrors exports:test ] |
| 237 | |
| 238 | **Logical operators and/or** |
| 239 | |
| 240 | The logical operators and/or can be used in inventory queries: |
| 241 | |
Petr Michalec | ab9cac3 | 2017-09-18 17:35:54 +0200 | [diff] [blame^] | 242 | .. code-block:: yaml |
| 243 | |
Petr Michalec | ad44117 | 2017-09-18 17:18:10 +0200 | [diff] [blame] | 244 | $[ exports:test_value if exports:test_zero == 0 and exports:test_one == self:value ] |
| 245 | |
| 246 | The individual elements of the if statement are evaluated and combined with the logical operators starting from the |
| 247 | left and working to the right. |
| 248 | |
| 249 | |
| 250 | **Inventory query example** |
| 251 | |
| 252 | Defining a cluster of machines using an inventory query, for example to open access to a database server to a |
| 253 | group of nodes. Given exports/parameters for nodes of the form: |
| 254 | |
| 255 | .. code-block:: yaml |
| 256 | |
Petr Michalec | ab9cac3 | 2017-09-18 17:35:54 +0200 | [diff] [blame^] | 257 | # for all nodes requiring access to the database server |
| 258 | exports: |
| 259 | host: |
| 260 | ip_address: aaa.bbb.ccc.ddd |
| 261 | cluster: _some_cluster_name_ |
Petr Michalec | ad44117 | 2017-09-18 17:18:10 +0200 | [diff] [blame] | 262 | |
| 263 | .. code-block:: yaml |
| 264 | |
Petr Michalec | ab9cac3 | 2017-09-18 17:35:54 +0200 | [diff] [blame^] | 265 | # for the database server |
| 266 | parameters: |
| 267 | cluster_name: production-cluster |
| 268 | postgresql: |
| 269 | server: |
| 270 | clients: $[ exports:host:ip_address if exports:cluster == self:cluster_name ] |
Petr Michalec | ad44117 | 2017-09-18 17:18:10 +0200 | [diff] [blame] | 271 | |
Petr Michalec | ab9cac3 | 2017-09-18 17:35:54 +0200 | [diff] [blame^] | 272 | This will generate a dictionary with an entry for node where the ``export:cluster`` key for a node is equal to the |
| 273 | ``parameter:cluster_name`` key of the node on which the inventory query is run on. Each entry in the generated dictionary |
| 274 | will contain the value of the ``exports:host:ip_address`` key. The output dictionary (depending on node definitions) |
Petr Michalec | ad44117 | 2017-09-18 17:18:10 +0200 | [diff] [blame] | 275 | would look like: |
| 276 | |
| 277 | .. code-block:: yaml |
| 278 | |
Petr Michalec | ab9cac3 | 2017-09-18 17:35:54 +0200 | [diff] [blame^] | 279 | node1: |
| 280 | ip_address: aaa.bbb.ccc.ddd |
| 281 | node2: |
| 282 | ip_address: www.xxx.yyy.zzz |
Petr Michalec | ad44117 | 2017-09-18 17:18:10 +0200 | [diff] [blame] | 283 | |
| 284 | For nodes where exports:cluster key is not defined or where the key is not equal to self:cluster_name no entry is made |
| 285 | in the output dictionary. |
| 286 | |
| 287 | In practise the exports:cluster key can be set using a parameter reference: |
| 288 | |
| 289 | .. code-block:: yaml |
| 290 | |
Petr Michalec | ab9cac3 | 2017-09-18 17:35:54 +0200 | [diff] [blame^] | 291 | exports: |
| 292 | cluster: ${cluster_name} |
| 293 | parameters: |
| 294 | cluster_name: production-cluster |
Petr Michalec | ad44117 | 2017-09-18 17:18:10 +0200 | [diff] [blame] | 295 | |
| 296 | The above exports and parameter definitions could be put into a separate class and then included by nodes which require |
| 297 | access to the database and included by the database server as well. |