minikube options about ctlptl HOT 7 CLOSED

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"
}

from ctlptl.

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

from ctlptl.

@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.

from ctlptl.

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?

from ctlptl.

@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.

from ctlptl.

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

from ctlptl.

ya, that's a fair point

from ctlptl.