==================
reclass to-do list
==================

Common set of classes
---------------------
A lot of the classes I have set up during the various stages of development of
|reclass| are generic. It would probably be sensible to make them available as
part of |reclass|, to give people a common baseline to work from, and to
ensure a certain level of consistency between users.

Testing framework
-----------------
There is rudimentary testing in place, but it's inconsistent. I got
side-tracked into discussions about the philosphy of mocking objects. This
could all be fixed and unified.

Also, storage, outputters, CLI and adapters have absolutely no tests yet…

Configurable file extension
---------------------------
Right now, ``.yml`` is hard-coded. This could be exported to the
configuration file, or even given as a list, so that ``.yml`` and ``.yaml``
can both be used.

Verbosity, debugging
--------------------
Verbose output and debug logging would be a very useful addition to help
people understand what's going on, where data are being changed/merged, and to
help solve problems.

Default classes
---------------
Through the configuration file, it should be possible to define a set of
default classes that are applied to all nodes (before anything else).

This would be covered by the next point:

Wildcards, regexp→class mapping
-------------------------------
I envision the ability to define mappings between regexps and classes, e.g.::

    /^www\d+/   →  webservers
    /\.ch\./    →  hosted@switzerland

These classes would be applied before a YAML file matching the actual hostname
would be read and merged.

Data from CMS for interpolation
-------------------------------
Depending on the CMS in question, it would be nice if |reclass| had access to
the host-specific data (facts, grains, etc.) and could use those in parameter
interpolation. I can imagine this working for Salt, where the ``grains``
dictionary (and results from previous external node classifiers) is made
available to the external node classifiers, but I am not convinced this will
be possible in Ansible and Puppet.

Ideally, |reclass| could unify the interface so that even templates can be
shared between the various CMS.