Hi,
I've seen a couple posts related to cloud-automation setup but they haven't addressed my specific issue so I hope this isn't a duplicate.
I'm following the instructions from csoc-free-commons-steps.md (very nice btw!) and get an error when trying to deploy the kubernetes cluster.
The AdminVM finished successfully and I've modified the EKS config.tfvars per the instructions. I then ran plan and apply and get this error at the end:
module.eks.null_resource.config_setup (local-exec): Unable to connect to the server: getting credentials: exec: exit status 1
Error: Error applying plan:
1 error occurred:
* module.eks.null_resource.config_setup: Error running command 'bash fsp-commons-test_output_EKS/init_cluster.sh': exit status 1. Output: could not get token: could not create session: CredentialRequiresARNError: credential type credential_source requires role_arn, profile cdistest
Presumably, this relates to my .aws/config file, which has the cdistest profile. It's true that there is no role_arn param in the file and I don't know what role I would put in there.
How can I troubleshoot this?
Thanks!
John
Hi Viktorija,
I could create the role but don't know what permissions it requires. Is this something that should have been created by an install separate script or do I create it manually? I haven't found it explained in the docs.
Thanks!
Oh! I see....this is the arn of the IAM role I attached to the EC2
It seems happy now. Thank you!
1 Like
Hi @Viktorija,
I'm past the kubernetes setup and on to the "roll all". Unfortunately, this fails when trying to connect to the RDS instances. Specifically, the psql connection for all three dbs is timing out. The RDS instances seem to be configured correctly as is the VPC peering.
Any suggestions on how to troubleshoot?
Thanks
John
Maybe logs could provide more information?
I wonder if you would like to join our slack channel where Gen3 enthusiast share their experience in setting up and configuring Gen3?
Yes, please. That would be great
John
Hi @jdamask! We sent you the invite
Thanks @Viktorija.
I don't see it yet (maybe hung up in spam filter) but wanted to update this thread in case anyone else experiences this.
The problem stems from VPC peering route table. The VPC I ran the install from has multiple subnets but only one was included in the table. It turns out, the scripts selected a different subnet from the one my adminVM was in, which was why the psql client couldn't connect.
Since the config file only takes parameters for the peered VPC and CIDR, I'm guessing the codebase selects the first subnet it encounters and adds a route for it. If you could point me to the code where this is implemented?
Thanks
John
We resent you an invitation. I see you already joined slack and raised similar question there.