| martin f. krafft | cc8851d | 2013-08-27 13:43:16 +0200 | [diff] [blame] | 1 | ================== |
| 2 | reclass to-do list |
| 3 | ================== |
| 4 | |
| martin f. krafft | cbaf4c8 | 2013-08-27 13:47:59 +0200 | [diff] [blame^] | 5 | Common set of classes |
| 6 | --------------------- |
| 7 | A lot of the classes I have set up during the various stages of development of |
| 8 | |reclass| are generic. It would probably be sensible to make them available as |
| 9 | part of |reclass|, to give people a common baseline to work from, and to |
| 10 | ensure a certain level of consistency between users. |
| 11 | |
| martin f. krafft | cc8851d | 2013-08-27 13:43:16 +0200 | [diff] [blame] | 12 | Testing framework |
| 13 | ----------------- |
| 14 | There is rudimentary testing in place, but it's inconsistent. I got |
| 15 | side-tracked into discussions about the philosphy of mocking objects. This |
| 16 | could all be fixed and unified. |
| 17 | |
| 18 | Also, storage, outputters, CLI and adapters have absolutely no tests yet… |
| 19 | |
| 20 | Configurable file extension |
| 21 | --------------------------- |
| 22 | Right now, ``.yml`` is hard-coded. This could be exported to the |
| 23 | configuration file, or even given as a list, so that ``.yml`` and ``.yaml`` |
| 24 | can both be used. |
| 25 | |
| 26 | Verbosity, debugging |
| 27 | -------------------- |
| 28 | Verbose output and debug logging would be a very useful addition to help |
| 29 | people understand what's going on, where data are being changed/merged, and to |
| 30 | help solve problems. |
| 31 | |
| 32 | Default classes |
| 33 | --------------- |
| 34 | Through the configuration file, it should be possible to define a set of |
| 35 | default classes that are applied to all nodes (before anything else). |
| 36 | |
| 37 | This would be covered by the next point: |
| 38 | |
| 39 | Wildcards, regexp→class mapping |
| 40 | ------------------------------- |
| 41 | I envision the ability to define mappings between regexps and classes, e.g.:: |
| 42 | |
| 43 | /^www\d+/ → webservers |
| 44 | /\.ch\./ → hosted@switzerland |
| 45 | |
| 46 | These classes would be applied before a YAML file matching the actual hostname |
| 47 | would be read and merged. |
| 48 | |
| 49 | Data from CMS for interpolation |
| 50 | ------------------------------- |
| 51 | Depending on the CMS in question, it would be nice if |reclass| had access to |
| 52 | the host-specific data (facts, grains, etc.) and could use those in parameter |
| 53 | interpolation. I can imagine this working for Salt, where the ``grains`` |
| 54 | dictionary (and results from previous external node classifiers) is made |
| 55 | available to the external node classifiers, but I am not convinced this will |
| 56 | be possible in Ansible and Puppet. |
| 57 | |
| 58 | Ideally, |reclass| could unify the interface so that even templates can be |
| 59 | shared between the various CMS. |