Question: SSH Key name validation is not done in Kickstart UI for AWS Cluster Creation?

[karuppiah7890]

I was using TCE v0.6.0 and trying out AWS Standalone Cluster creation using the Kickstart UI. While filling in the fields, most fields had suggestions / drop downs with valid values and there was validation being done too I think. Except for the SSH Key name field (in the first step) though. It seemed like SSH key name field was a free flow text field without suggestions and random names for example ok let me pass to the next step with no validation errors. I wasn't sure what to provide in the SSH key name field until I read this link from a team mate - https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.0/vmware-tanzu-kubernetes-grid-10/GUID-install-tkg-aws.html#register-ssh . I think it's good to do some validations so that users get early feedback? Or is this already being done and it's just not available in TCE v0.6.0 yet?

[karuppiah7890]

cc @miclettej

[miclettej]

Hi @karuppiah7890 client side SSH key validation can be a tricky thing and a bit error prone. Golang offers reliable libraries for this type of validation on the backend, but we have not found one for the UI that has proven to be accurate and reliable. We've discussed this issue with Vui and other leads previously and opted to use only validation on the backend for the CLI and leave the UI as is.

[karuppiah7890]

Oh, I meant validation that a key named "xyz" exists kind of validation. Also suggestions, like for vSphere I saw suggestions for fields like Datacenter, Resource Pools etc, similar to that suggestions to show the available SSH keys (for EC2) for a given region. Is that what you are referring to too?

[miclettej]

Ah sorry I read your first question too quickly. We have also had some discussions around this area of validating the SSH key name for AWS. Actually, suggestions were that we retrieve a list of available SSH key names but to do that it requires that the target account allows access in that regard. That was proven to be an unreliable approach, but maybe we can do something similar to your suggestion. I am unable to tag Sudarshan Aji, who works on the AWS/CLI side of things. I'll ping him with this thread.

[karuppiah7890]

Thanks @miclettej !

[dsu-igeek]

It would be nice to check for the key pair, or put the error message out into the top level logs. I got this when I specified a key pair that didn't exist in the region:

✘ [1105 12:06:49.32909]: init.go:166] unable to set up management cluster, : unable to wait for cluster and get the cluster kubeconfig: error waiting for cluster to be provisioned (this may take a few minutes): cluster creation failed, reason:'BastionHostFailed', message:'6 of 8 completed'

and it took a while to find the message that gave the actual reason the failure occurred:

2021-11-05T19:33:32.5728283Z stderr F E1105 19:33:32.572543 1 awscluster_controller.go:228] controllers/AWSCluster "msg"="failed to reconcile bastion host" "error"="failed to run instance: InvalidKeyPair.NotFound: The key pair '<key pair name>' does not exist\n\tstatus code: 400, request id: 3b677ae0-63b8-48f9-a0c8-425e2c1ee0d5" "awsCluster"="<aws cluster>" "cluster"="<cluster>" "namespace"="tkg-system"

[karuppiah7890]

Yeah, we need a fail fast strategy to avoid waiting for a long time just to end up with an error and also avoid spending lot of time on debugging

[miclettej]

@saji-pivotal would it be possible for us to surface AWS key pair errors earlier and at top level logs with more detail? If so, can I reassign this to you?

[saji-pivotal]

@miclettej Please feel free to reassign this to me. I will be able to investigate this further later this week.