Consul Provider does not seem to query consul

[packplusplus]

I've tried this with 0.5.0. Working on testing 0.4.2 (doesn't support AWS Env variables)

It doesn't seem to make a call to consul. I left tcpdump -i lo port 8500 running in another window, and no packets show up on a plan or an apply. They do show up on the curls.

Here's my .tf

provider "consul" { 
  address = "127.0.0.1:8500"
  datacenter = "us-east-aws"
  scheme = "http"
} 

resource "consul_keys" "app" {
    key {
    name = "vpc_id"
    path = "terraform_sg/vpc_id"
    }
    key {
    name = "region"
    path = "terraform_sg/aws_region"
    }
}

provider "aws" {
  region = "${consul_keys.app.var.region}"
}

resource "aws_security_group" "consul-test" {
    name = "consul-test"
    description = "consul-test"
    vpc_id = "${consul_keys.app.var.vpc_id}"

    ingress {
        from_port = 22 
        to_port = 22
        protocol = "tcp"
        cidr_blocks = ["0.0.0.0/0"]
    }
}

Output of plan:

 terraform plan ./
There are warnings and/or errors related to your configuration. Please
fix these before continuing.

Errors:

  * 1 error(s) occurred:

* 1 error(s) occurred:

* Not a valid region: ${consul_keys.app.var.region}

Output of apply:

terraform apply ./
There are warnings and/or errors related to your configuration. Please
fix these before continuing.

Errors:

  * 1 error(s) occurred:

* 1 error(s) occurred:

* Not a valid region: 

and some KVs

$ curl -s localhost:8500/v1/kv/terraform_sg/aws_region | jq -r '.[] | .Value' | base64 --decode; echo
us-east-1

$ curl -s localhost:8500/v1/kv/terraform_sg/vpc_id | jq -r '.[] | .Value' | base64 --decode; echo
vpc-DONTSTEALMYVPCBRO

$ consul --version
Consul v0.5.0
Consul Protocol: 2 (Understands back to: 1)

[packplusplus]

consul 0.5.0 does not de-reference consul_keys on plan, but will on apply. If you do not have a tfstate file, neither plans or applies will work if you have any resources in your tf file. However, if you create a file like

provider "consul" {

address = "127.0.0.1:8500"

datacenter = "us-east-aws"

scheme = "http"

}

resource "consul_keys" "app" {

key {

name = "vpc_id"

path = "terraform_sg/vpc_id"

}

key {

name = "region"

path = "terraform_sg/aws_region"

}

}
provider "aws" {

region = "${consul_keys.app.var.region}"

}

and run terraform apply it will create the right state file. From then on you can add your regular resource in there and continue to apply them. However you will never be able to run a plan, so hey, GFL.

[phinze]

@packplusplus this is great debugging work. I'm picking this up now - thanks for the head start!

[packplusplus]

To make the tf file for 0.4.2 I pulled scheme = "http" out and added secret_key and access_key to the aws provider. Test gave me packets on the plan, and a tfstate file if I ripped out the security group resource and did an apply. With the security group resource I get a cycle error on the plan and the apply.

Error configuring: 1 error(s) occurred:
* Cycle: consul_keys.app, provider.aws, aws_security_group.consul-test (destroy tainted), consul_keys.app (destroy tainted)

Do you need anything else? Happy to test any patches (I already have a build env).

[phinze]

No this is good. I'll keep you posted on the debugging process. Pretty close to the end of the day for me over here, so might not be able to get a fix in today. But I'll make sure this thread has the latest info.

[phinze]

Alright I've done a bunch of exercising of consul_keys over here, and after seeing things seeming to work and re-reading your reports I realized that this is a combination of two things:

(1) You're expecting the initial plan to query consul. I can see how you might expect this, but because "consul_keys" is implemented as a Terraform Resource, it's got a CRUD lifecycle internally, and on the first Plan Terraform only knows it must create this "resource" and record its ID to the state. Subsequent plans have recorded the ID and can perform a "refresh" of the data, which queries consul. It's just a limitation of the model, but it generally works out okay in practice.

(2) You're trying to interpolate the configuration of a provider with the results of a resource. This is not something we support yet - provider config happens at an early stage, which means that only input variables are allowed to be interpolated in provider config. The first error message you got is a clue that interpolation is not happening: * Not a valid region: ${consul_keys.app.var.region}

If you do not have a tfstate file, neither plans or applies will work if you have any resources in your tf file!

I was unable to reproduce a scenario where an "apply" would not result in the consul keys being read. If you have some repro steps there I'm happy to continue to investigate.

[packplusplus]

I now completely understand the behavior and why what I was trying to do wasn't ever going to work. I would argue it would be reallllly nice to reference keys in your provider config. I will have a script generate a tfvariables file instead (maybe use fsconsul for that).

Since the original tf file references a consul variable, if you don't have a tfstatefile (as in you removed it or were starting out net new), no applies can happen because of issue 2.

Is there any documentation that explains that provider configs cannot use resource results? Am I too greedy in asking not to close this issue until the documentation on the consul provider notes that consul variables cannot be used to configure providers? Or maybe a generic warning on any of the providers?

[phinze]

Not too greedy at all. You were confused based on very reasonable
assumptions and unclear error messages.

Seems like a specific error message when interpolation is attempted in
provider config would be helpful. Any suggestions on where we should tweak
the docs? (The website source is all in this repo)

On Friday, May 8, 2015, Patrick Flaherty notifications@github.com wrote:

I now completely understand the behavior and why what I was trying to do
wasn't ever going to work. I would argue it's reallllly nice to reference
keys in your provider config. I will have a script generate a tfvariables
file instead (maybe use fsconsul for that).

Since the original tf file references a consul variable, if you don't have
a tfstatefile (as in you removed it or were starting out net new), no
applies can happen because of issue 2.

Is there any documentation that explains that provider configs cannot use
resource results? Am I too greedy in asking not to close this issue until
the documentation on the consul provider notes that consul variables cannot
be used to configure providers? Or maybe a generic warning on any of the
providers?

—
Reply to this email directly or view it on GitHub
#1879 (comment)
.

[phinze]

Going to close this since the original issue was solved. Ideas on improved messaging are still welcome!

[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.