Skip to content
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

Resource consul_key_prefix does not honor datacenter set in provider consul #13

Closed
hashibot opened this issue Jun 13, 2017 · 4 comments
Closed
Labels

Comments

@hashibot
Copy link

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


The documentation at https://www.terraform.io/docs/providers/consul/r/key_prefix.html says that datacenter is option and that it by default uses from the provider setup. But that was not true in our case.

Terraform Version

v0.9.3

Affected Resource(s)

Please list the resources as a list, for example:

  • consul_key_prefix

Terraform Configuration Files

Provider:

variable "consul_dc" {}
variable "consul_acl_token" {}

provider "consul" {
  datacenter = "${var.consul_dc}"
  token = "${var.consul_acl_token}"
}
module "dtabs"  { source = "modules/dtabs"  dc = "${var.consul_dc}" }

Resource (without datacenter) original:

resource "consul_key_prefix" "keys" {
  path_prefix = "${var.prefix}${var.path}"
  subkeys = "${data.external.dtabs_keys.result}"
}

Resource (with datacenter) modified/fixed:

resource "consul_key_prefix" "keys" {
  datacenter = "${var.dc}" 
  path_prefix = "${var.prefix}${var.path}"
  subkeys = "${data.external.dtabs_keys.result}"
}

Expected Behavior

Since datacenter is already passed in via provider "consul", it should have chosen the correct datacenter.

Actual Behavior

It chose the wrong datacenter.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. Use "Resource (without datacenter) original" resource above
  2. terraform apply
@hashibot hashibot added the bug label Jun 13, 2017
@Chhed13
Copy link

Chhed13 commented Dec 17, 2017

It seems that it is on the consul/api library side

func getDC(d *schema.ResourceData, client *consulapi.Client) (string, error) {
...
       // terraform-provider-consul/consul/resource_consul_keys.go:337
	info, err := client.Agent().Self()  
...
}

client initialized with correct datacenter from provider, but info return structure with datacenter of the agent that it requests. Self agent doesn't necessary present in the same datacenter as requested in provider - here is a mismatch.
It concerns all getDC usages (that 14), not just consul_key_prefix
It looks like with current consul/api interface and getDC function it can't work the other way.
Maybe logic of using datacenter from provider should be re-written or documents should be updated?

@amanjeev
Copy link

Thanks @Chhed13! It seems that it would be nice to have a provider datacenter as well, if possible. What do you think?

@Chhed13
Copy link

Chhed13 commented Dec 26, 2017

According to the architecture of provider and resources datacenter form provider and from resource - is 2 different things and datacenter (or any field) can not be re-used in resource from provider for sure, because this field will be taken not directly from config, but from self agent.
@amanjeev actually we have both, they both with the same names - 1 in provider config, 1 in resource config. The biggest mess is this getDC function, which tries to fallback to provider's variant if resource's one not set

@pearkes
Copy link
Contributor

pearkes commented May 1, 2018

Thanks for the good discussion here. Going to close as a duplicate of #8.

@pearkes pearkes closed this as completed May 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants