search

kinvolk / lokomotive

🪦 DISCONTINUED Further Lokomotive development has been discontinued. Lokomotive is a 100% open-source, easy to use and secure Kubernetes distribution from the volks at Kinvolk
https://kinvolk.io/lokomotive-kubernetes/
Apache License 2.0
320 stars 49 forks source link

Refine lokoctl application flow #821

Open invidian opened 4 years ago

invidian commented 4 years ago

To help with solving #603, we should define how the lokoctl application flow should look like and then refactor existing code to match that flow.

I would imagine something like this:

  1. Load configuration ~files~ - lokoctl tasks are driven by configuration and we aim for that to be the source of the truth for the actions (e.g. #142). This means regardless of the task, we should always try to read the configuration.

    Notes:

    • Configuration should be represent as Go structures, HCL should be treated independently from the configuration and it's purpose should be to transform HCL files into Go structures (#604).
    • Information what configuration files to load should be passed from CLI (flags, env variables etc.) into HCL loader.

  2. With configuration loaded, we should validate it, to ensure we work on the valid data (#23). This should also give user a quick feedback if there are any issues with the configuration.

    Notes:

    • Configuration validation should be decentralized, meaning each struct should have it's own validation methods and each struct should know how to validate their children. This allows calling validate function only once at the top of the configuration, which should validate entire configuration tree.

  3. With valid configuration, CLI sub-command will be controlling which action to execute. As our execution flow is driven by the configuration, action methods should be associated with the configuration itself.

    Notes:

    • CLI should control and pass the configuration to the actions. Things like which components to install for component apply sub-command.
    • If given action has too many parameters, they should perhaps be wrapped in a struct, so

Extra notes:

johananl commented 4 years ago

I do agree we should revise the naming we use but I'm not sure about "stack". Some thoughts:

I always try to stick to the way I naturally think about the problem when trying to figure out the correct data model. For example:

"I want a cluster with components X and Y deployed on the AWS platform".

From the above, I can extract 3 key terms:

Now, the question is how they relate to one another:

"My cluster has 2 components."

The above hints at a one-to-many relationship between "cluster" and "component", namely a cluster contains one or more components.

"My cluster runs on AWS."

This one is a bit trickier for figuring out the data model as it's not so obvious what "runs on" mean, however since we don't control the AWS layer I would argue that the platform (AWS/Packet etc.) is a dimension of "cluster", i.e. this cluster is of type AWS (just like "this cluster is of size 3"). To demonstrate the "wrong" direction, I wouldn't try to say "my AWS has 2 clusters" :confused: