-
Notifications
You must be signed in to change notification settings - Fork 49
Refactor platform handling #716
Comments
A relevant discussion: #655 (comment) |
IMO The main constraint for the refactoring would be to make platform-specific packages (e.g.
Following actions should be generic to all platforms:
Configuration loading should be done separately from the platform-specific package, perhaps in HCL package (which we do not have right now). I guess this can be left for later. |
Is it a must for baremetal to use matchbox? Cause I am exploring other projects in the same space. https://github.com/plunder-app/plunder and http://tinkerbell.org/ to name a few. |
@rugwirobaker I'm not sure what you mean, but you might also be interested in #392, where experimental support for Tinkerbell is implemented. |
@invidian just skimming through the code in |
@rugwirobaker ah, I know what you mean now. We also have #383 to actually rename baremetal to matchbox, so we can support more. |
@invidian is there somewhere a setup guide using Tinkerbell? |
There are some hints here: https://github.com/kinvolk/lokomotive/pull/392/files#diff-7196abe142cd5822d69f345a960f986fR1 For setting up Tinkerbell, follow https://tinkerbell.org/docs/setup/. For the configuration structure, you can look at https://github.com/kinvolk/lokomotive/pull/392/files#diff-f0ab264028d0de5d78c3665c00a126f2R31-R72. I hope that helps, given that the PR is not fully ready yet. |
General
At the moment the
platform
package has multiple responsibilities:We should consider refactoring the
platform
package to have a single purpose: defining the contents of a Lokomotive platform. The rationale for doing the refactor:Following the refactoring, the following should be true:
platform
package exposes a minimal API which allows specifying the "recipe" for deploying a Lokomotive cluster on a given cloud (or bare metal) platform. The package doesn't perform any API calls, file operations or other forms of I/O.platform
package doesn't depend on theterraform
package. Any code related to executing Terraform operations should be generic (i.e. not platform specific) and reside in theterraform
package.platform
package doesn't depend on theassets
package. Any code related to generating assets into the binary and extracting assets to disk should be generic and reside in theassets
package.Implementation
When implementing this change, we should look for cases where we have "specialized" logic for a platform and ideally eliminate such cases. This is important if we want to make Terraform-related code generic. An example of such specialized logic:
lokomotive/pkg/platform/packet/packet.go
Lines 142 to 160 in fee1edd
lokomotive/pkg/platform/aws/aws.go
Lines 143 to 152 in fee1edd
As can be seen above, the Packet implementation of
Initialize()
contains things like API token validation and DNS config validation whereas the AWS implementation of the same function does not.If we realize we can't make Terraform-related code completely generic, we can look into allowing arbitrary logic to be specified in a platform implementation, for example using callback functions. We should do our best to keep things well defined if we go in this direction. For example, we may want to consider defining a small set of "hooks" to allow a platform implementation to specific, for example, that some arbitrary logic needs to be run before/after executing
terraform apply
, before/after applying Lokomotive components etc.A central part of this refactoring should be re-examining the
Platform
interface and changing it so that it properly matches the responsibility of theplatform
package and exposes a limited set of methods which every platform implementation should implement.@invidian, @iaguis - FYI.
The text was updated successfully, but these errors were encountered: