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.
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…
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.
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.
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.
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.
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.
Right now, the adapters and the CLI look for the configuration file 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.