minikube options

[nicks]

Currently, the ctlptl API lets you pass a complete Kind config: https://pkg.go.dev/github.com/tilt-dev/ctlptl/pkg/api#Cluster

ctlptl then merges the cluster-independent options with a user-supplied Kind config.

We should do something similar with minikube flags, so you can do things like minikube start --vm=true --cni=cilium --kubernetes-version='v1.19.4' --bootstrapper=kubeadm, and ctlptl can ensure your cluster has the right settings. (This is a little tricky, because we want to make sure people aren't setting flags that are incompatible with how ctlptl sets up the cluster, but I think it can be done).

[cbcoutinho]

Minikube supports persisting options to a configuration file (e.g. ~/.minikube/config/config.json) on Linux; however, It appears that ctlptl does not respect this user configuration. It currently creates minikube clusters based on whatever the minikube installed defaults are

[nicks]

@cbcoutinho Thanks for the report!

One of the design goals of this project is to help infra engineers manage a dev environment for their team, see:
https://github.com/tilt-dev/ctlptl#goals

One of the big complaints we see is that a more junior engineer accidentally sets a personal config that makes their team's app run poorly, and doesn't understand why.

So depending on what particular config we're talking about, this may be deliberate. But if there are particular personal configs you think ctlptl should preserve and don't conflict with this design goal, we're open to talking about it.

[cbcoutinho]

I understand the goals of infrastructure teams regarding (naïve) local environments, At the same time, I don't think it's desirable to deviate too much from the behavior of invoking minikube explicitly and via a wrapper like ctlptl.

My particular local config is meant to match the remote clusters I'm currently working with, which I was surprised that ctlptl had ignored when creating the cluster. I'm sure you could think of much more exotic configurations (e.g. https://minikube.sigs.k8s.io/docs/handbook/filesync/), but those are arguably more advanced features that you should know you need if you decide the use them

{
    "container-runtime": "containerd",
    "driver": "kvm2"
}

[remram44]

I need this. The ctlptl only allows setting specific flags or --extra-config, but there are many minikube flags that are important for specific setups. For example --ports.

Why not accept any command-line flag in the ctlptl configuration?

[nicks]

@remram44 we do have an API for accepting minikube flags in the YAML configs, see d59471b, would totally accept a PR to add Ports

it's a little bit more complex than just forwarding flags, since we have to reconcile against what ctlptl is doing, and some flags are incompatible with how ctlptl sets it up.

[remram44]

Like I said, this is only for --extra-config and not any of the numerous other flags, even the harmless (to ctlptl) ones like --ports

[nicks]

ya, that's a fair point