Skip to content

better management of mixing flags and config #2902

@chendave

Description

@chendave

What happened?

pls see: kubernetes/kubernetes#113583 (comment)

the major reason to against the mix configuration is:

migrate users away from flags

but it is not clear why some of them are allowed for the mix configuration in the first place.

https://github.com/kubernetes/kubernetes/blob/0ae9aaacfa217b18652f34d6ef29f08a15851b0a/cmd/kubeadm/app/apis/kubeadm/validation/validation.go#L560-L573

func isAllowedFlag(flagName string) bool {
	allowedFlags := sets.New(kubeadmcmdoptions.CfgPath,
		kubeadmcmdoptions.IgnorePreflightErrors,
		kubeadmcmdoptions.DryRun,
		kubeadmcmdoptions.KubeconfigPath,
		kubeadmcmdoptions.NodeName,
		kubeadmcmdoptions.KubeconfigDir,
		kubeadmcmdoptions.UploadCerts,
		"print-join-command", "rootfs", "v", "log-file")
	if allowedFlags.Has(flagName) {
		return true
	}
	return strings.HasPrefix(flagName, "skip-")
}

What you expected to happen?

  • Kubeadm should have a consistent style for the configuration
  • If this is not possible, Kubeadm should make it clear why some of the flags are allowed the mix configuration, while other not.

How to reproduce it (as minimally and precisely as possible)?

Anything else we need to know?

### Tasks
- [x] `dry-run` flags should be configurable in each config API (init/join/reset/upgrade)
- [x] `skip-phases` should be configurable in the upgrade API
- [ ] deprecate flags that could be configured in the config file
- [ ] move the flags out of the allowed list for mix config which is configurable in the config
- [ ] evaluate all other flags in the list and see if we can make them configurable in the config file instead.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/clikind/cleanupCategorizes issue or PR as related to cleaning up code, process, or technical debt.kind/designCategorizes issue or PR as related to design.kind/featureCategorizes issue or PR as related to a new feature.lifecycle/frozenIndicates that an issue or PR should not be auto-closed due to staleness.priority/important-longtermImportant over the long term, but may not be staffed and/or may need multiple releases to complete.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions