doc/source/todo.rst

==================
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.

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.

Node environments
-----------------
At least Salt and Puppet support the notion of "environments", but the Salt
adapter just puts everything into the "base" environment at the moment.

Part of the reason that multiple environments aren't (yet) supported is
because I don't see the use-case (anymore) with |reclass|. If you still see
a use-case, then please help me understand it and let's figure out a good way
to introduce this concept into |reclass|.

Membership information
----------------------
It would be nice if |reclass| could provide e.g. the Nagios master node with
a list of clients that define it as their master. That would short-circuit
Puppet's ``storeconfigs`` and Salt's ``mine``.

Configuration file lookup improvements
--------------------------------------
Right now, the adapters and the CLI look for the :doc:`configuration file
<configfile>` in a fixed set of locations. On of those derives from
``OPT_INVENTORY_BASE_URI``, the default inventory base URI (``/etc/reclass``).
This should probably be updated in case the user changes the URI.

Furthermore, ``$CWD`` and ``~`` might not make a lot of sense in all
use-cases.

.. include:: substs.inc