-
I got very close to my first QHub cluster deployment (on AWS), but ran into a terraform error. I followed the steps in https://docs.qhub.dev/en/latest/source/03_tutorials_and_samples/1_project_setup_tutorial.html and https://docs.qhub.dev/en/latest/source/02_get_started/02_setup.html (with some necessary tweaks [1]). The qhub deploy -c qhub-config.yaml --dns-provider cloudflare --dns-auto-provision Here are the last several lines of the run-time messages: [terraform]: Warning: Applied changes may be incomplete
[terraform]:
[terraform]: The plan was created with the -target option in effect, so some changes
[terraform]: requested in the configuration may have been ignored and the output values may
[terraform]: not be fully updated. Run the following command to verify that no other
[terraform]: changes are pending:
[terraform]: terraform plan
[terraform]:
[terraform]: Note that the -target option is not suitable for routine use, and is provided
[terraform]: only for exceptional situations such as recovering from errors or mistakes, or
[terraform]: when Terraform specifically suggests to use it as part of an error message.
[terraform]:
[terraform]:
[terraform]: Error: error waiting for EKS Node Group (qhubcluster-dev:user) creation: AccessDenied: Amazon EKS Nodegroups was unable to assume the service-linked role in your account. Resource IDs: []
[terraform]:
[terraform]: on .terraform/modules/kubernetes/modules/aws/kubernetes/main.tf line 18, in resource "aws_eks_node_group" "main":
[terraform]: 18: resource "aws_eks_node_group" "main" {
[terraform]:
[terraform]: Afterwards I ran ...
[terraform]: module.kubernetes.aws_iam_policy.worker_autoscaling: Destruction complete after 32s
[terraform]: module.kubernetes.aws_iam_role.node-group: Destruction complete after 32s
[terraform]:
[terraform]: Error: Unauthorized
[terraform]:
[terraform]:
Problem encountered: Terraform error Thanks in advance. I can post complete logs if it helps. BTW, I wasn't sure where to post this. Traffic on both gitter and here stopped the last week of April, but I couldn't find concrete pointers to a more current communication platform other than a passing reference to Slack and an incomplete reference to gitter possibly being deprecated. Update: I'm using qhub 0.3.11 [1] For the |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 7 replies
-
Thank you very much for your report. GitHub Issues is the best place to post these for now. One point of confusion is that the qhub.dev docs redirected to 'latest' until yesterday, and now redirects to 'stable' (so the docs that would be in line with the 0.3.11 release). So that would have told you to set AWS_DEFAULT_REGION, whereas in the 'latest' (in development) branch that is actually not needed. I'm not too sure why Auth0 sometimes gives different subdomains. I have seen None of this really addresses your issue... I would guess (as I'm sure you would too!) that somehow the AWS keys you've provided don't have permissions to do everything needed on EKS, or it could just be a timing issue where the permissions aren't ready. I haven't come across this myself, but I'll ask around to see if anyone else has. |
Beta Was this translation helpful? Give feedback.
-
I'm closing old discussions in a repo cleanup effort. Feel free to re-open if needed. |
Beta Was this translation helpful? Give feedback.
Thank you very much for your report. GitHub Issues is the best place to post these for now.
One point of confusion is that the qhub.dev docs redirected to 'latest' until yesterday, and now redirects to 'stable' (so the docs that would be in line with the 0.3.11 release). So that would have told you to set AWS_DEFAULT_REGION, whereas in the 'latest' (in development) branch that is actually not needed.
I'm not too sure why Auth0 sometimes gives different subdomains. I have seen
.eu.auth0.com
whereas others do just get.auth0.com
... I'll see if I can find out why, or at least update the docs to note this discrepancy.None of this really addresses your issue... I would guess (as I'm sure you …