Proposal: Replace the current Makefile with a dedicated CLI tool

[DEiselt]

Note: I am relatively new to the project and this proposal is based on my observations while working with the k8s-cluster-api-provider repo. But this only reflects my view on it and i am happy about any input or critic regarding this proposal.

Description

I propose to replace the Makefile currently used for managing the k8s-cluster-api-provider setup for a dedicated CLI tool to increase maintainability and extensibility. While the Makefile does work for the current use-case, i think that it isn't the intended use of Make and also complicates further extension. Two apparent examples would be the implementation of conditional logic being a mix of what (limited) support exists in Make paired with "shell magic", as well as how files and text is processed currently. Keeping the already visible occurrences in mind, both of these examples would, in my opinion, greatly profit from using a proper programming language.

Pros vs Cons

Pros

• proper file handling
• proper text processing
• possibility to use language specific libraries (i.e. yaml support, openstack api and others)
• option to use tooling to improve code quality (i.e. linter) and thus maintainability
• improved consistency (i.e. how to read and handle config values and their defaults)
• improved extensibility
• possible usage outside of the scope of this repo (other SCS tooling)
• proper logging ¹
• proper error handling ²

Cons

• initial development efforts
• migration from the Makefile

Possible implementation

I already thought about how this could look like, but any feedback on this is highly requested.

As a choice of language i would select Python in combination with the Click package to create a robust foundation for the CLI tool. This is because Python is widely known, easy to maintain and provides support for (nearly) everything currently used in the Makefile. The first step would be to mirror the current Makefile to make it as backwards compatible as possible.

Reason for this proposal

This section aims to provide some context for this proposal while being an optional read. While i am sure that there is a way to make it work with Make, i am a great fan of the "using the right tool for the job" mentality.

I was already questioning the usage of Make for this use-case for a while but the idea to create this proposal manifested while working on #158 . The gist of this issue is too autodetect the availability zone if not explicitly provided. While this looks like a relatively simple task, implementing it in the Makefile in a clean way ended up being quite complicated. Starting from aquiring and storing the AZ info from Openstack, my current approach ended up in querying the API multiple times for the same information due to limitations with how to store and process the given data. Given the knowledge that this is possible with the current Makefile, every possible implementation i tried or thought of felt "hacked together" rather than a robust solution.

Footnotes

1. Usage of a logging lib vs "echo" or "$(info *)" with arbitrary messages ↩

2. Make only supports premature exits through errors (i.e. $(shell exit 1)) ↩

[jschoone]

Hi @DEiselt, thanks for your proposal and the detailed informations!
As we discussed before I think this is a valuable topic to discuss. It probably will not make it to this repo, but we could bring it to the Central API where a tool like this will likely be requested by users/operators.
While it's questionable that it'll be implemented in Python, the concept stays the same I guess.