Destruction order for dependent providers is incorrect

[partamonov]

Situation:

• I have RDS database created with aws_rds_instance resource
• I have MySQL/Postgre/MSSQL providers with _database resource

For MySQL/Postgre/MSSQL provider endpoint is created RDS.

But I found that if I'm doing terraform destroy RDS instance is destroyed before database on it. I checked dependency graph and found that _database resource is not linked to RDS resource. The only option here is to add depends_on flag

Should we think how to fix dependencies or at least we should document this somewhere, may be on MySQL/Postgre/MSSQL providers pages

My graph for 2 cases in attached files:
with_depends_on.txt
without_depends_on.txt

[catsby]

For MySQL/Postgre/MSSQL provider endpoint is created RDS

Hey @partamonov – do you have a configuration that demonstrates this? If you could share it (minus any secrets) that would help. Assuming you're using the interpolation for the endpoint, this should certainly work..

Thanks

[partamonov]

Sure, I will post. In short, I use it as

module "rds" {
  ...
}

provider mysql {
  host "${module.rds.address}"
  ...
}

mysql_database "mydb" {
  name = "mydb"
}

This won't create dependency. Terraform version is 0.6.9

[partamonov]

provider "aws" {
    access_key = "${var.aws_key}"
    secret_key = "${var.aws_secret_key}"
    region = "eu-west-1"
}

module "rds" {
  source = "../modules/rds_provisioned"

  purpose = "${var.purpose}"
  customer = "${var.customer}"
  security_group_id = "${module.aws_iam.security_group_id}"
  instance_size = "${var.rds_instance_size}"
  instance_admin = "${var.rds_instance_admin}"
  instance_password = "${var.rds_instance_password}"
  subnet = "${var.subnet}"
  subnet_backup = "${var.subnet_backup}"
}

provider "mssql" {
  endpoint = "${module.rds.address}"
  username = "${module.rds.username}"
  password = "${var.rds_instance_password}"
}

resource "mssql_database" "mydb" {
  name = "mydb"
}

### RDS module returns
output "address" {
  value = "${aws_db_instance.db.address}"
}
output "username" {
  value = "${aws_db_instance.db.username}"
}

[partamonov]

@catsby, please see above

[catsby]

Thank you @partamonov ! We'll look into this

[mtekel]

Related problem here (also with postgresql provider), but in our case TF graph does show the dependency, yet TF behaves as if the dependency was not there: #5340

[partamonov]

Version 0.6.14
Graph looks better now, but I still see that in current example mysql provider is initialized before resource is created on which provider is dependent

digraph {
        compound = "true"
        newrank = "true"
        subgraph "root" {
                "[root] aws_db_instance.db" [label = "aws_db_instance.db", shape = "box"]
                "[root] aws_db_subnet_group.rds" [label = "aws_db_subnet_group.rds", shape = "box"]
                "[root] aws_ecs_cluster.cis" [label = "aws_ecs_cluster.cis", shape = "box"]
                "[root] aws_iam_instance_profile.cissaas" [label = "aws_iam_instance_profile.cissaas", shape = "box"]
                "[root] aws_iam_role.cissaas" [label = "aws_iam_role.cissaas", shape = "box"]
                "[root] aws_iam_role.role_service" [label = "aws_iam_role.role_service", shape = "box"]
                "[root] aws_iam_role_policy.ecs" [label = "aws_iam_role_policy.ecs", shape = "box"]
                "[root] aws_iam_role_policy.ecs_service" [label = "aws_iam_role_policy.ecs_service", shape = "box"]
                "[root] aws_security_group.docker" [label = "aws_security_group.docker", shape = "box"]
                "[root] mysql_database.app" [label = "mysql_database.app", shape = "box"]
                "[root] provider.aws" [label = "provider.aws", shape = "diamond"]
                "[root] provider.mysql" [label = "provider.mysql", shape = "diamond"]
                "[root] provider.template" [label = "provider.template", shape = "diamond"]
                "[root] template_file.user_data" [label = "template_file.user_data", shape = "box"]
                "[root] aws_db_instance.db" -> "[root] aws_db_subnet_group.rds"
                "[root] aws_db_instance.db" -> "[root] aws_security_group.docker"
                "[root] aws_db_instance.db" -> "[root] provider.aws"
                "[root] aws_db_subnet_group.rds" -> "[root] provider.aws"
                "[root] aws_ecs_cluster.cis" -> "[root] provider.aws"
                "[root] aws_iam_instance_profile.cissaas" -> "[root] aws_iam_role.cissaas"
                "[root] aws_iam_instance_profile.cissaas" -> "[root] aws_iam_role_policy.ecs"
                "[root] aws_iam_instance_profile.cissaas" -> "[root] provider.aws"
                "[root] aws_iam_role.cissaas" -> "[root] provider.aws"
                "[root] aws_iam_role.role_service" -> "[root] provider.aws"
                "[root] aws_iam_role_policy.ecs" -> "[root] aws_iam_role.cissaas"
                "[root] aws_iam_role_policy.ecs" -> "[root] provider.aws"
                "[root] aws_iam_role_policy.ecs_service" -> "[root] aws_iam_role.role_service"
                "[root] aws_iam_role_policy.ecs_service" -> "[root] provider.aws"
                "[root] aws_security_group.docker" -> "[root] provider.aws"
                "[root] mysql_database.app" -> "[root] provider.mysql"
                "[root] provider.mysql" -> "[root] aws_db_instance.db"
                "[root] template_file.user_data" -> "[root] provider.template"
        }
}

provider "mysql" {
    endpoint = "${aws_db_instance.db.endpoint}"
    username = "${var.rds_admin}"
    password = "${var.rds_password}"
}

resource "mysql_database" "app" {
    name = "my_awesome_app"
    #default_character_set = "latin2"
    #default_collation = "latin2_general_ci"
}

And as result I see that ${aws_db_instance.db.endpoint} is not passed to mysql provider during initial run
Debug error messages from provider.
Initial run

 endpoint - , dial tcp: missing address

Second run

endpoint - blah.eu-west-1.rds.amazonaws.com:3306

[partamonov]

@catsby do you have any ideas

[mitchellh]

I finally have a fix for this queued up in the referenced PR. :)

[ghost]

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.