Standalone-cluster create using kickstart UI detects clusterconfig file

[jpmcb]

What this PR does / why we need it

This PR introduces some better UX when using the kickstart UI during standalone-cluster create.

A user now does not need to specify a cluster name when using the kickstart UI:

$ tanzu standalone-cluster create --ui 

This launches the UI and the user can go through it as normal. If the user specifiys a cluster name (which is optional in the UI), the cluster config file will be named by that cluster. So for example, in the UI, when naming a cluster johns-test-cluster, the following file is created:

/home/jmcb/.tanzu/clusterconfigs/johns-test-cluster.yaml

If a user does not specify a cluster name, a random UID is still generated for the clusterconfig file (which was the default behavior before this PR).

This now makes the UX of deleting a standalone-cluster much better. A user can now simply specify:

tanzu standalone-cluster delete johns-test-cluster

and the command will also look in .tanzu/clusterconfigs/ for the file named johns-test-cluster.yaml. This is in line with how delete works for users who used the CLI to create a cluster. And maybe in the future, we merge the two experiences so there aren't two different directories for these cluster configs.

Which issue(s) this PR fixes

Related to #650
Also ref https://github.com/vmware-tanzu-private/tkg-cli/commit/40cdcc7916793609971fdabef82e6456a6e0a951 for changes made in the web/server package to save the cluster config files with the cluster name (which is also related to #

Describe testing done for PR

Deployed an AWS standalone cluster using the UI workflow and successfully deleted the cluster without having to specify the --file for the cluster config. Also deployed a standalone CAPD cluster using the CLI and there was no deprecation in the UX for this workflow.

Special notes for your reviewer

In the future, it would probably be beneficial to have this refactored deeper into the stack so that we aren't managing .tanzu/clusterconfigs at the plugin level.

[stmcginnis]

Sweet! Testing this locally.

[stmcginnis]

Tested this locally with a deployment to AWS. Performed deployment entirely through the UI.

Verified the ~/.tanzu/clusterconfig yaml file matched the name I provided in the UI.

Successfully deployed standalone cluster.

Successfully able to run tanzu standalone-cluster delete $CLUSTER_NAME when done.

[stmcginnis]

Failed with vSphere.

Deployment worked fine. Gave it a name of vspheresa. Name was properly reflected in the VMs that were created, but not in the YAML file:

ls ~/.tanzu/clusterconfigs
m6a4j35d07.yaml

Running tanzu standalone-cluster delete vspheresa kicked off OK, but looks like it tried to use vspheresa.yaml, couldn't find it and fell back to default config:

❯ tanzu standalone-cluster delete vspheresa
Loading bootstrap cluster config for standalone cluster at '/Users/smcginnis/.tanzu/tce/configs/vspheresa_ClusterConfig'
no bootstrap cluster config found - looking for UI bootstrap config file
Loading UI bootstrap cluster config for standalone cluster at '/Users/smcginnis/.tanzu/clusterconfigs/vspheresa.yaml'
no bootstrap cluster config found - using default config
timeout duration of at least 15 minutes is required, using default timeout 30m0s
Deleting standalone cluster 'vspheresa'. Are you sure? [y/N]: y
....
Error: standalone cluster deletion failed
Cause: unable to delete standalone cluster: unable to initialize providers: failed to get provider components for the "vsphere:v0.7.6" provider: failed to perform variable substitution: value for variables [VSPHERE_PASSWORD, VSPHERE_USERNAME] is not set. Please set the value using os environment variables or the clusterctl config file, this can be possible because of the outbound connectivity issue. Please check deployed nodes for outbound connectivity.

[jpmcb]

@stmcginnis this should be resolved in my most recent go.mod bump. I hadn't set this in the other 3 providers, only AWS: https://github.com/vmware-tanzu-private/tkg-cli/commit/9a0d210affa25252cfacb5f8f7fb24819edb758f
So no, the UI should create the cluster-config file based on the cluster name for all 4 providers

[stmcginnis]

Confirmed latest update fixed the yaml file naming for vSphere deployment.