Feature Request: Provide an option for passing a config file for addon configure command.

[ghost]

What Happened?

Currently when configuring addons with the command:

minikube addons configure <addon>

eg:

minikube addons configure registry-creds

The user is prompted to input the values one by one, eg:

Do you want to enable AWS Elastic Container Registry? [y/n]:

and so on.

Some times it easier to provide a config file containing so that the values can be read from this.

The request is for a "-c" local flag to the addon configure command, eg:

minikube addons configure registry-creds -c ~/.minikube/configs/registry-creds-config.json

An example of this file is:

{
  "enableAWSEcr": "enable",
  "awsEcrConfigs": {
     "awsAccessID": "changeme",
     "awsAccessKey": "changeme",
     "awsSessionToken": "changeme",
     "awsRegion": "changeme",
     "awsAccount": "changeme",
     "awsRole": "changeme"
  },
  "enableGCR": "disable",
  "gcrConfigs": {
     "gcrPath": "changeme",
     "gcrURL": "https://gcr.io"
  },
  "enableDockerRegistry": "disable",
  "dockerConfigs": {
     "dockerServer": "changeme",
     "dockerUser": "changeme",
     "dockerPass": "changeme"
  },
  "enableACR": "disable",
  "acrConfigs": {
     "acrURL": "changeme",
     "acrClientID": "changeme",
     "acrPassword": "changeme"
  }
}

The parsing of this config will be specific to the kind of addon. (Here we have chosen a naming style consistent with the style within the code itself, egcmd/minikube/cmd/config/configure.go, but we can adopt other stratgies here).

Also to consider:

• Whether to have a single options file for all addons
• [Preferred] addon specific options file - that MUST be passed to override default behavior always prompting.

Attach the log file

This is not an issue but a feature request.

Operating System

macOS (Default)

Driver

Docker

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale