MySQL provider. Issue with cycle dependencies and graph (0.6.12, 0.6.14)

[hashibot]

This issue was originally opened by @partamonov as hashicorp/terraform#5687. It was migrated here as part of the provider split. The original body of the issue is below.

---

resource "aws_db_instance" "db" {
  identifier = "${lower("${var.name}")}"
  allocated_storage = "5"
  engine = "mysql"
  engine_version = "5.6.27"
  instance_class = "db.t2.micro"
  username = "admin"
  password = ""
  multi_az = false
  apply_immediately = true
  db_subnet_group_name = "${aws_db_subnet_group.rds.id}"
  vpc_security_group_ids = ["fgdgfgdgdf"]
  publicly_accessible = false
  backup_retention_period = 0
}

/*provider "mysql" {
    endpoint = "${aws_db_instance.db.endpoint}"
    username = "${aws_db_instance.db.username}"
    password = "gdfgfdgdfgdf"
}

resource "mysql_database" "discovery" {
    depends_on = ["aws_db_instance.db"]
    name = "discovery"
    provisioner "local-exec" {
      command = "D:/tools/mysql/bin/mysql.exe --host=${aws_db_instance.db.address} --user=${aws_db_instance.db.username} --password=dfgdfgdfg --protocol=TCP --database=${self.name} < CREATE.sql"
    }
}

This part of code causing issues. (see attched create.log)

And if I'm creating RDS instance first and as second run I'm creating DBs everything is fine, but destroy failing with

aws_db_instance.db: Refreshing state... (ID: cisdocker)
mysql_database.preview: Refreshing state... (ID: preview)
mysql_database.discovery: Refreshing state... (ID: discovery)
mysql_database.deployer: Refreshing state... (ID: deployer)
Error creating plan: 1 error(s) occurred:

* Cycle: mysql_database.discovery (orphan), mysql_database.deployer (orphan), mysql_database.preview (orphan), aws_db_instance.db (destroy), aws_db_subnet_group.rds (destroy), aws_db_subnet_group.rds, aws_db_instance.db, provider.mysql

And once again commenting mysql databases part and apply did the trick for first run and second run can be with destroy flag

create.txt

[andricicezar]

Any news about this? I still run in this bug.

Version:

$ ./terraform version
Terraform v0.11.3
+ provider.docker v0.1.1
+ provider.mysql v1.0.1

Proof of concept:

provider "docker" {
  host = "unix:///var/run/docker.sock"
}

resource "docker_image" "database" {
  name = "mysql:5"
}

resource "docker_container" "database" {
  name  = "database"
  image = "${docker_image.database.latest}"
  env = [ "MYSQL_ROOT_PASSWORD=example" ]
}

provider "mysql" {
  endpoint = "${docker_container.database.ip_address}:3306"
  username = "root"
  password = "example"
}

resource "mysql_database" "example" {
  name = "example"
}

Output: (same for apply)

$ ./terraform plan
Error: Error running plan: 1 error(s) occurred:

* provider.mysql: dial tcp 127.0.0.1:3306: getsockopt: connection refused

[mclavel]

Hi @andricicezar , i think the issue is when the mysql provider tried to connect to the database, but this resource doesn't exist yet.

I have the same issue with Google Cloud Platform Provider and Mysql Provider. I sended a PR for this problem.

[RobbieMcKinstry]

This feels like a fairly common use case. I'm surprised there haven't been more people asking about this. The MySQL provider is basically useless if you can't use it to configure a database after provisioning the server.

[mechtron]

Although it made me sad, I ended up using this hack to overcome this limitation.

[mclavel]

In our company we use a docker image with terraform and mariadb service to run plans. Using this approach, the mysql provider try connect to the local database (when the new database don't exist), but the configurations it's applied in the new server (using flag depends_on, when it's up).