Add keypair fixes to k3s

[dkeightley]

Add the same changes to k3s that were added for RKE2

Tested with create_ssh_key_pair = true and also with a pre-created keypair

[glovecchi0]

Hey @dkeightley,
I tested the PR with the following terraform.tfvars file:

prefix                = "glovecchio"
aws_region            = "eu-west-1"
server_instance_count = 1
worker_instance_count = 1
rancher_hostname      = "glovecchio"
rancher_password      = "Mypassword.1234"

Below is the error:

...
...
...
╷
│ Warning: Value for undeclared variable
│ 
│ The root module does not declare a variable named "rancher_hostname" but a value was found in file "terraform.tfvars". If you meant to use this value,
│ add a "variable" block to the configuration.
│ 
│ To silence these warnings, use TF_VAR_... environment variables to provide certain "global" settings to all configurations in your organization. To
│ reduce the verbosity of these warnings, use the -compact-warnings option.
╵
╷
│ Error: Invalid function argument
│ 
│   on main.tf line 81, in data "local_file" "ssh_private_key":
│   81:   filename   = pathexpand(module.k3s_first_server.ssh_key_path)
│     ├────────────────
│     │ while calling pathexpand(path)
│     │ module.k3s_first_server.ssh_key_path is null
│ 
│ Invalid value for "path" parameter: argument must not be null.
╵
 glovecchio  …  upstream  aws  k3s   k3s-keypair-fix 

Did I do something wrong?

[dkeightley]

Thanks @glovecchi0, can you retest with the latest commit?

I have adjusted the default to create a keypair when no tfvars is set (either A or B)

[glovecchi0]

Hi @dkeightley,
I'm continuing the testing with the terraform.tfvars file described above.

Below the result:

I think it's necessary to ensure that a new VPC/Subnet is created by default to resolve the error and that the rancher_hostname variable is added to resolve the warning.

[glovecchi0]

Hi @dkeightley,
After you created the default VPC and Subnet, which is selected if the variables are not configured, I successfully completed the above step.

Unfortunately, the execution stops here:

(I tried destroying and recreating twice)

I don't want the default SSH connection timeout to be insufficient for starting the VM.

[glovecchi0]

Hi @dkeightley,
With the latest changes, it worked perfectly.

There is however a problem with the destroy which must be executed 2 times in a row to work correctly.
Could it make sense to open an issue for this? I encounter the same problem in GCP modules. Maybe we need to modify the Rancher modules.