Updating local cluster with revised config.

GrahamDumpleton commented 2 weeks ago

Is your feature request related to a problem? Please describe.

Prior to 3.0 installer changes, when using local kind cluster, you could update the global Educates config in place by editing the local config using educates admin config edit and then running educates admin platform config update. In 3.0 the later command has gone away with the config of deployed Educates being updated by running educates admin platform deploy. Problem is that when using educates create-cluster it uses the hidden local config automatically, and since educates admin platform deploy has to be passed the config explicitly, then it would be necessary to do:

educates admin config edit
educates admin config view > config.yaml
educates admin platform deploy --config config.yaml

This is non obvious.

Describe the solution you'd like

One solution might be that --config not be marked as required argument to CLI option processing and the CLI looks at the Educates deployed to the cluster and picks up some annotation from educates-config config map in the educates-config namespace that indicates is a managed local Kind cluster created using educates create-cluster(where --config wasn't used) and in that situation will use the hidden local config automatically if no --config argument is supplied. If it isn't a managed local Kind cluster then flag an error that --config argument is required.

Describe alternatives you've considered

A quick workaround solution would be that if the --config option to educates admin platform deploy is an empty string, that the hidden local config is used. IOW:

func (o *PlatformDeployOptions) Run() error {
    var fullConfig *config.InstallationConfig
    var err error = nil

    if o.Config == "" {
        fullConfig, err = config.NewInstallationConfigFromUserFile()
    } else {
        fullConfig, err = config.NewInstallationConfigFromFile(o.Config)
    }

Additional information

Related issue:

Ability to view educates-config stored values from when configuration created. https://github.com/vmware-tanzu-labs/educates-training-platform/issues/426

GrahamDumpleton commented 2 weeks ago

The annotations on the config map should also track whether --with-locals-secrets was true when hidden local config used (whether by new default that it would per issue #432 or explicitly), so that can be reapplied when allowing educates admin platform deploy is allowed to be used with no --config option.

jorgemoralespou commented 2 weeks ago

I would probably go a different direction. When you create the cluster, or when you deploy the platform, a configmap with the configuration will be saved as educates-config in educates-config configmap. What I suggest is that:

educates admin platform config view shows the content of the configmap in the connected cluster (if available). With connected I mean the cluster that is accesible via kubeconfig or via the kubeconfig and context params to the command in the CLI
educates admin platform config edit let's you update this configuration in the cluster, so the configmap will be updated.
educates admin platform deploy when no configuration file is given and there is a connected cluster, will use this configuration. Or even have an educates admin platform update command that will work without config, but still keep the deploy command with required configuration.

We should probably need to add some annotations to the config, to know when the configuration has been modified but not applied, and when the configuration has been applied, and potentially do version control of configuration (like kapp-controller) and save last 5 configurations.

If we do this, we can probably remove educates admin config commands, and have educates admin cluster create work without configuration (use the defaults for kind), or with a configuration file for kind customisation but don't have the local configuration saved in the user directory area as we do today. All the configuration that is specific to kind, like bind ip or listen-address are only used when the cluster is created, so in order to change them, the cluster would need to be deleted and created again anyways.

vmware-tanzu-labs / educates-training-platform