-
Notifications
You must be signed in to change notification settings - Fork 9.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Creating aws_elasticsearch_domain can't be done due to absence of AWSServiceRoleForAmazonElasticsearchService role #5218
Comments
Not even creating a microcluster from the AWS Console seemed to help. |
Looking at https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/slr-es.html, I get the impression that this error ONLY (?) occurs if/when a VPC is specified for ES. |
Yes, indeed when I create my micro-cluster and instead choose "VPC access", then I get the |
The IAM role was then created, and while the one I created in the AWS console is building (will take ten, fifteen minutes), I'm running Terraform to create my "real" cluster with Terraform. Looking at the IAM role, it have the
... with the trust entity
... in the path |
You can just add this ressource before creating your domain:
This will create the needed role for ES |
Seems that aws_iam_service_linked_role resource fails if the role has already been created outside the current terraform state which makes this hard to couple with the creation of an es cluster. |
* Fix issue related to ES Service linked role See hashicorp/terraform-provider-aws#5218 * Fix repetition
@SylH You save my day! Thank you! |
It may also need to add a dependency on this role from ES domains like
It will prevent issues on destroy:
The error on destroy is raised because the role cannot be destroyed if there's one ES domain in the VPC. ES domain must be destroyed before the role. |
I had the same issue and I got over it by creating (through the GUI) a test ES domain first, that created the AWSServiceRoleForAmazonElasticsearchService and after that I was able to apply my terraform code successfully. It is kind of the obvious workaround but I'm commenting this anyway in case someone else got stuck. |
We just ran into this now and it looks like the This is an easy fix, however I'm not sure of the benefit of doing so as we don't really automatically create service linked roles on the first run anywhere else and it's going to be an absolute pain to test that this works nicely in an automated way. I'd recommend that we pull this out entirely and straight up recommend that users create the service linked role themselves either in a separate location (as this is an account wide thing and you may have multiple ES clusters in an AWS account) or use This approach then keeps us consistent with other resources with service linked roles available and doesn't add awkward, unexpected things (creating IAM things implicitly is a bit unusual, even if it is a service linked role) and means we don't have an untested block of code in the code base. @bflad thoughts? |
@tomelliff that's a great write up and I'd agree with you -- recommend we remove that code as you suggested (merging in 2.0 of the AWS provider just to be safe) and in its place we should certainly add information on the |
(I've assigned to myself for tracking, but anyone can feel free to make the above PRs) |
It's necessary to have already created the elasticsearch.amazonaws.com service linked role before attempting to create a VPC based ES cluster. This can either be done separately from the ES cluster creation (useful if you have multiple ES clusters in an AWS account because the service linked role can only be created once) or the aws_elastcisearch_domain resource needs to wait for it to be created by using depends_on. See the discussion on hashicorp#5218 for more information.
This is not currently working due to the error message being different than expected ('cannot be found' instead of the expected 'Role not found'). Instead of fixing the bug it was decided that a better approach would be to force users to explicitly create the IAM service linked role instead of doing it for them if it didn't exist. This more closely matches what we do elsewhere and also means we aren't implicitly creating an IAM role despite the user not trying to do that which is particularly dangerous with IAM even if it is just a service linked role. This is also reasonably necessary because it's going to be an absolute pain to catch this in acceptance tests as it's something that gets implicitly created once per account and then not managed by Terraform after that. See the discussion on hashicorp#5218 for more information.
@bflad sorry for the delay, made these changes a few days back while on the train but didn't push them until now. Let me know on each of the PRs if there's any issues with them. |
@eunomie i still get the same error:
despite having:
|
Please fix the example:
... |
The |
@jgutierrez-adl As per the docs the proper
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks! |
Community Note
Terraform Version
Terraform v0.11.7
Affected Resource(s)
Terraform Configuration Files
Debug Output
https://gist.github.com/sarunask/69b7e612d92ee992d7a70f506623f35f
Panic Output
No panic
Expected Behavior
ES Cluster created
Actual Behavior
Terraform gave error:
status code: 404, request id: 2fe1c895-89d7-11e8-8212-c38ddc7e67d2
Steps to Reproduce
terraform apply
Important Factoids
In current AWS account there are no previous ElasticSearch clusters.
References
The text was updated successfully, but these errors were encountered: