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
321 stars 49 forks source link

Component to support `enable` field to skip installation #1408

Open ipochi opened 3 years ago

ipochi commented 3 years ago

@joaquimrocha proposed this request that currently in Lokomotive when applying cluster with lokoctl , we either execute lokoctl cluster apply by installing the cluster and all the configured components or skip all the components.

It would be nice if all the components supported enabled field, which if set as false skips installing that component.

invidian commented 3 years ago

Maybe we can make --skip-components be allowed to be defined multiple times and specify list of components to skip there?

invidian commented 3 years ago

What would be the point of skipping given component all the time @joaquimrocha?

joaquimrocha commented 3 years ago

It'd be for e.g. easily keeping the config for that component but not apply it until needed. Say you want to provide an example configuration but leave the decision of applying the component to the user, then it'd be nice to say "just enable the component".

I did suggest this before knowing that we can have components separated into their own config file, which kind of makes it easier to accomplish the same effect. It's not blocking anything ATM so there's no urgency from my side, and I am understand if you decline it.

invidian commented 3 years ago

Say you want to provide an example configuration but leave the decision of applying the component to the user, then it'd be nice to say "just enable the component".

The components already have default configuration built-in. And act of "enabling the component is to create a component block, or uncomment it, following the declarative specification of desired state. I'm not sure if adding concept of enabling on top of it make much sense.

I did suggest this before knowing that we can have components separated into their own config file, which kind of makes it easier to accomplish the same effect.

Yes, you can have component configs in separate files as well :+1: But by default we consume all config files in working directory, so I don't think they can be so-easily disabled. But my guts feeling is that using files as an interface here is simple and effective.