Open Primetalk opened 4 years ago
Though,
$ terraform state list
module.community_slack_message_processor_lambda.aws_cloudwatch_event_rule.rule[0]
module.user_engagement_scheduler_lambda.aws_cloudwatch_event_rule.rule[0]
module.user_objectives_lambda.aws_cloudwatch_event_rule.rule[0]
module.user_profile_lambda.aws_cloudwatch_event_rule.rule[0]
Looks like a bug in terraform
After switching to use localstack (It seems that we hadn't used it before...)
TestBooks 2020-05-15T12:16:17+03:00 command.go:168: module.api.aws_api_gateway_account.demo: Refreshing state... [id=api-gateway-account]
coverage: [no statements]
panic: test timed out after 30m0s
Hangs on
TestBooks 2020-05-15T14:11:05+03:00 command.go:168: module.api.aws_api_gateway_account.demo: Refreshing state... [id=api-gateway-account]
TestBooks 2020-05-15T20:13:00+03:00 command.go:168: module.reporting_db.module.db_instance.aws_db_instance.this[0]: Creating...
TestBooks 2020-05-15T20:13:04+03:00 command.go:168:
TestBooks 2020-05-15T20:13:04+03:00 command.go:168: Error: Provider produced inconsistent result after apply
TestBooks 2020-05-15T20:13:04+03:00 command.go:168:
TestBooks 2020-05-15T20:13:04+03:00 command.go:168: When applying changes to aws_dynamodb_table.user_communities, provider
TestBooks 2020-05-15T20:13:04+03:00 command.go:168: "registry.terraform.io/-/aws" produced an unexpected new value for was
TestBooks 2020-05-15T20:13:04+03:00 command.go:168: present, but now absent.
TestBooks 2020-05-15T20:13:04+03:00 command.go:168:
TestBooks 2020-05-15T20:13:04+03:00 command.go:168: This is a bug in the provider, which should be reported in the provider's own
TestBooks 2020-05-15T20:13:04+03:00 command.go:168: issue tracker.
It tries to create RDS tables in the real us-west-2
region.
Localstack doesn't support creating RDS instances locally.
Per Localstack Pro pricing there is a support for RDS in Pro version.
This means that we might have to either upgrade to Localstack Pro, or get rid of localstack altogether.
Discussion:
Relational Database Service (RDS)
LocalStack supports a basic version of RDS for testing. Currently, it is possible to spin up PostgreSQL databases on the local machine; support for MySQL and other DB engines is under development and coming soon.
@ctcreel, @sunnylbk We might want to change our RDS to PostgreSQL
TestBooks 2020-05-20T12:00:14+03:00 command.go:168: Error: error deleting CloudWatch Event Rule (test_user_profile_every_5_min): ValidationException: Rule can't be deleted since it has targets.
...
TestBooks 2020-05-20T12:00:14+03:00 command.go:168: Error: Error deleting IAM Role (test_strategy-slack-message-processor-lambda-go): DeleteConflict: Cannot delete entity, must detach all policies first.
...
Looks like terraform has some issues and does not know a correct order of resource destruction. Terraform previously had similar issue: https://github.com/hashicorp/terraform/issues/2761
Manually deleted the resources that terraform could not destroy.
Error creating EIP: AddressLimitExceeded: The maximum number of addresses has been reached
After removing old IP addresses it's finally completed. We still have some old Elastic IPs: https://us-west-2.console.aws.amazon.com/vpc/home?region=us-west-2#Addresses:
Plan: 0 to add, 0 to change, 370 to destroy.
Destroy complete! Resources: 370 destroyed.
Plan: 370 to add, 0 to change, 0 to destroy.
Error creating EIP: AddressLimitExceeded
Looks like it does not remove Elastic IPs automatically.
terraform apply
/destroy
works on local machine and deploy to real AWS. This process does not look very reliable. If it failed for some reason, the infrastructure is left in uncertain intermediate state and requires manual cleanup. (I guess, it's because terraform state is not transactional. See an interesting discussion here.)
With Localstack there is another issue - Elastic IP doesn't seem to be supported. This means that even if we create most of our infrastructure in localstack, some of it will be deployed to the real AWS. And probably elastic IP won't work/fail because AWS wouldn't know about the other parts of infrastructure.
This makes me think that end-2-end automatic test of our infrastructure is not possible at the moment.
What we could think instead is split our infrastructure into a few modules that we can deploy/destroy independently and then create a few tests that will be testing some of the modules. And Elastic IP will be left untested.
Rules are used in
schedule
. And terraform cannot destroy rules due to the above issue.