What is configurator?
For the OpenCHAMI project, I wrote a little tool called “configurator” to do some config file rendering magic. It ended up not being useful and I suspect a part of that is due to how complicated it is to set up and understand. Also, as handy, dynamic, and extensible the configurator’s plugin templating system might have seem, it’s use-case was not very clear. Was it a cloud-init replacement or was it meant to solve a completely different problem?
Why rewrite the service?
This question is what lead me to consider re-writing the tool/service entirely (aside from having my own uses). I had to re-think exactly what was I trying to do in the first place with the original implementation. I decided that it would be better to simply rewrite the entire thing and give it a new name. So, I changed the name of the service from configurator to makeshift.
I started by removing some of the abstractions from the original service that added unnecessary complexity with little gain. Therefore, this new tool has no concept of a Target, Template, or Generator plugins (although plugins still exist). In fact, it cannot render templates on its own…instead it’s just a driver program for external plugins. But the plugin system has been completely revamped and now the workflow is now simple; everything is designed around downloading, uploading, data stores, profiles, and plugins.
Using the new tool may feel similar to a glorified FTP server at first, but that’s intentional. For example, we can start a server instance and download files both with and without rendering using the same command.
# start the service
makeshift serve --root ./tests --init -l debug
# download a file without any rendering
makeshift download -p help.txt -l debug
# download a file using the jinja2 plugin and default profile
makeshift download -p help.txt --plugins jinja2 --profiles default -l debug