doc/source/todo.rst - packaging/sources/reclass - Gitiles

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

 This could also provide a more realistic example to users on how to use
 |reclass|.

 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…

 The testing framework should also incorporate the example classes mentioned
 above.

 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.

 Actually, I don't think this is such a good idea. If we create too many
 options right now, it'll be harder to unify later. Please also see `issue #17
 <https://github.com/madduck/reclass/issues/17`_ for a discussion about this.

 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.

 On the other hand, providing CMS-specific data to reclass will make people
 depend on it, meaning Salt cannot be used with multiple tools anymore.

 The way to deal with that would be to map grains, facts, whatever the CMS
 calls them, to a shared naming scheme/taxonomy, but that's a painful task,
 I think. It would mean, however, that even templates could be shared between
 CMSs if they only use the data provided by reclass (i.e. grains/facts become
 pillar data).

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

 The way I envision this currently is to provide something I call "inventory
 queries". For instance, the Nagios master node's reclass data would contain
 the following (``$[…]`` would denote interpolation to create a list, a bit
 like list comprehension)::

   parameters:
     nagios:
       hosts: $[nagios:master == SELF.nodename]

 This would cause |reclass| to iterate the inventory and generate a list of all
 the nodes that define a parameter ``nagios:master`` whose value equals to the
 name of the current node.

 This could be greatly simplified. For instance, we could simply limit
 comparisons against the name of the current node and just specify

 ::

   $[nagios:master]

 which would be expanded to a list of node names whose pillar data includes
 ``${nagios:master}`` that matches the current node's name.

 Or it could be made arbitrarily complex and flexible, e.g. any of the
 following::

   $[nagios:master == SELF.nodename]                  # replace with nodename
   $[nagios:master == SELF.nodename | nodename]       # name replacement value
   $[nagios:master == SELF.nodename | nagios:nodeid]  # replace with pillar data
   $[x:nagios:nodeid foreach x | x:nagios:master == SELF.nodename]
   …

 I'd rather not code this up from scratch, so I am looking for ideas for reuse…

 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.

 However, this might be better addressed by the following point:

 Adapter class hierarchy
 -----------------------
 At the moment, adapters are just imperative code. It might make more sense to
 wrap them in classes, which customise things like command-line and config file
 parsing.

 One nice way would be to generalise configuration file reading, integrate it
 with command-line parsing, and then allow the consumers (the adapters) to
 configure them, for instance, in the Salt adapter::

   config_proxy = ConfigProxy()
   config_proxy.set_configfile_search_path(['/etc/reclass', '/etc/salt'])
   config_proxy.lock_config_option('output', 'yaml')

 The last call would effectively remove the ``--output`` config option from the
 CLI, and yield an error (or warning) if the option was encountered while
 parsing the configuration file.

 Furthermore, the class instances could become long-lived and keep a reference
 to a storage proxy, e.g. to prevent having to reload storage on every request.

 Node lists
 ----------
 Class mappings are still experimental, and one of the reasons I am not too
 happy with them right now is that one would still need to provide node files
 for all nodes for ``inventory`` invocations. This is because class mappings
 can assign classes based on patterns or regular expressions, but it is not
 possible to turn a pattern or regular expression into a list of valid nodes.

 `Issue #9 <https://github.com/madduck/reclass/issues/9>`_ contains a lengthy
 discussion on this. At the moment, I am unsure what the best way forward is.

 Inventory filters
 -----------------
 As described in `issue #11 <https://github.com/madduck/reclass/issues/11>`_:
 provide a means to limit the enumeration of the inventory, according to node
 name patterns, or using classes white-/blacklists.

 .. include:: substs.inc
	==================
	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.

	This could also provide a more realistic example to users on how to use
	\|reclass\|.

	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…

	The testing framework should also incorporate the example classes mentioned
	above.

	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.

	Actually, I don't think this is such a good idea. If we create too many
	options right now, it'll be harder to unify later. Please also see `issue #17
	<https://github.com/madduck/reclass/issues/17`_ for a discussion about this.

	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.

	On the other hand, providing CMS-specific data to reclass will make people
	depend on it, meaning Salt cannot be used with multiple tools anymore.

	The way to deal with that would be to map grains, facts, whatever the CMS
	calls them, to a shared naming scheme/taxonomy, but that's a painful task,
	I think. It would mean, however, that even templates could be shared between
	CMSs if they only use the data provided by reclass (i.e. grains/facts become
	pillar data).

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

	The way I envision this currently is to provide something I call "inventory
	queries". For instance, the Nagios master node's reclass data would contain
	the following (``$[…]`` would denote interpolation to create a list, a bit
	like list comprehension)::

	parameters:
	nagios:
	hosts: $[nagios:master == SELF.nodename]

	This would cause \|reclass\| to iterate the inventory and generate a list of all
	the nodes that define a parameter ``nagios:master`` whose value equals to the
	name of the current node.

	This could be greatly simplified. For instance, we could simply limit
	comparisons against the name of the current node and just specify

	::

	$[nagios:master]

	which would be expanded to a list of node names whose pillar data includes
	``${nagios:master}`` that matches the current node's name.

	Or it could be made arbitrarily complex and flexible, e.g. any of the
	following::

	$[nagios:master == SELF.nodename] # replace with nodename
	$[nagios:master == SELF.nodename \| nodename] # name replacement value
	$[nagios:master == SELF.nodename \| nagios:nodeid] # replace with pillar data
	$[x:nagios:nodeid foreach x \| x:nagios:master == SELF.nodename]
	…

	I'd rather not code this up from scratch, so I am looking for ideas for reuse…

	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.

	However, this might be better addressed by the following point:

	Adapter class hierarchy
	-----------------------
	At the moment, adapters are just imperative code. It might make more sense to
	wrap them in classes, which customise things like command-line and config file
	parsing.

	One nice way would be to generalise configuration file reading, integrate it
	with command-line parsing, and then allow the consumers (the adapters) to
	configure them, for instance, in the Salt adapter::

	config_proxy = ConfigProxy()
	config_proxy.set_configfile_search_path(['/etc/reclass', '/etc/salt'])
	config_proxy.lock_config_option('output', 'yaml')

	The last call would effectively remove the ``--output`` config option from the
	CLI, and yield an error (or warning) if the option was encountered while
	parsing the configuration file.

	Furthermore, the class instances could become long-lived and keep a reference
	to a storage proxy, e.g. to prevent having to reload storage on every request.

	Node lists
	----------
	Class mappings are still experimental, and one of the reasons I am not too
	happy with them right now is that one would still need to provide node files
	for all nodes for ``inventory`` invocations. This is because class mappings
	can assign classes based on patterns or regular expressions, but it is not
	possible to turn a pattern or regular expression into a list of valid nodes.

	`Issue #9 <https://github.com/madduck/reclass/issues/9>`_ contains a lengthy
	discussion on this. At the moment, I am unsure what the best way forward is.

	Inventory filters
	-----------------
	As described in `issue #11 <https://github.com/madduck/reclass/issues/11>`_:
	provide a means to limit the enumeration of the inventory, according to node
	name patterns, or using classes white-/blacklists.

	.. include:: substs.inc