Hi,
“terraform apply” on terraform 0.13.0beta2 always ask yes/no confirmation to read data source. It is by design ?
It’s right to always read data source to allow depends_on extended support, but why asking for confirmation as this does not produce any changes to the infra ?
Hi @trung,
I think you are talking about the Terraform Registry community providers beta rather than the Terraform CLI v0.13.0 beta. Is that right?
If so, the community providers beta is a separate process than Terraform v0.13.0 beta which is being run by the Terraform Registry team at HashiCorp. I believe they’ve halted new beta applications for the moment because they have enough participants for the first round of feedback. The beta may reopen again in the future if they need some additional feedback, but that’s not being driven by the Terraform Core team (which is the team I work on) and so I can’t say for certain when or if that will happen. There’ll be guidance on the Terraform Registry site as the situation changes, though.
Hi @apparentlymart,
probably you are right as terraform version return registry.terraform as aws provider:
Terraform v0.13.0-beta2
the two processes you speak about (Terraform community providers vs Terraform CLI) refers to providers or to terraform cli itself ?
I can change this behavior setting provider using Explicit Provider Source Locations ? I cannot find aws provider specifications. Reading your “Draft: Upgrading to Terraform v0.13” I thought default was hashicorp… not so clear for me.
This behavior was changed in Terraform 0.13.0beta3 or provider aws v2.69.0. No more apply confirmation for data block (read).
terraform version
Terraform v0.13.0-beta3
+ provider registry.terraform.io/hashicorp/aws v2.69.0
rc1 was scheduled for release yesterday per the github issue: https://github.com/hashicorp/terraform/issues/25016
What’s the new date?
yeah, I was thinking the same thing. It is now 5 days later. Any word on the next release?
Hi all,
As is often the case with prerelease builds, we got lots of good feedback on beta3 about some remaining rough edges and so we’re holding RC1 in order to respond to the subset of that feedback that must be included before v0.13.0 final. We expect to release RC1 once that work is complete.
@apparentlymart - Thanks very much for this update. We’re extremely excited to start putting 0.13 into broad use.
Will you also be posting timeline updates to the GitHub issue or should I watch here primarily for updates?
@jurgenweber @alexjurkiewicz @aaronsteers1 I’ve posted an updated set of dates on the GitHub issue. The new dates are:
RC1 is scheduled to ship Wednesday, July 22
GA is scheduled to ship Monday, August 10
I was really excited to get my hands on this as I was hoping it would finally resolve one of my issues around for_each and modules. I have a use case where I want to ingest a json template with a series of AWS account IDs, and then invoke a module to create an IAM role in each of the accounts. To do this requires assuming a role in each account, so upon each invocation the module should read the role_arn and then use that to deploy the resources. Unfortunately it appears the release candidate can’t do that:
Error: Module does not support for_each
on main.tf line 4, in module "remote_role":
4: for_each = local.data
Module "remote_role" cannot be used with for_each because it contains a nested
provider configuration for "aws", at modules/iam/provider.tf:1,10-13.
This module can be made compatible with for_each by changing it to receive all
of its provider configurations from the calling module, by using the
"providers" argument in the calling module block.
My provider block inside the module is just this:
provider aws {
assume_role {
role_arn = "arn:aws:iam::${var.account_id}:role/OrganizationAccountAccessRole"
}
}
Is this an RC limitation or something more permanent?
Hi all,
the current draft upgrade guide to Terraform v0.13 states it is possible to write modules compatible with both v0.12 and v0.13:
Fuller instructions will follow on the main Terraform documentation website
after the v0.13.0 release, including some guidance on how you can write
modules that are compatible with both v0.12 and v0.13 during a transitional
period.
See https://github.com/hashicorp/terraform/blame/guide-v0.13-beta/draft-upgrade-guide.md#L125-L128
Does that also apply to modules that use providers that were moved outside the hashicorp namespace like datadog and signalfx?
How are we supposed to define the source for those and yet be backward compatible with 0.12?
I’m trying to use for_each feature on modules in 0.13.0-RC1 to consume iam roles from another module that provides them as output.
E.g.: 2 types of containers exist “api” and “worker” each assumes its own AWS iam role. I then want to allow each of that role to access SQS via resource policy by passing the output of multiple module call as array to SQS module:
module "base_remote_state" {
source = "git::git......:user/remote_base.git"
for_each = toset(["api" , "worker"])
component_name = each.key
environment = "dev"
role_arn = "arn:aws:sts::123456789012:role/OperatorRole"
region = "us-west-2"
}
module "sqs-stack" {
source = "git::git@g...../sqs_stack.git"
......
application_iam_roles = [module.remote_states.*.role_arn]
.....
}
this doesn’t work as each instance module call is named by the for_each index so that I need to pass the names explicitely like this:
[module.remote_states.api.role_arn, module.remote_states.worker.role_arn] instead of wildcard.
Is there a gracefull way to workaround that?
except using null_resource and template_file
UPD: the only way I found for now is using locals:
locals {
role_arns = [
for module_instance in module.base_remote_state:
module_instance.role_arn
]
}Hi @paulbygrave,
There is another discussion Module does not support for_each where we’ve been talking about that error.
The short answer to your question is that this is a permanent restriction and that modules containing provider configurations are incompatible with module for_each, count, and depends_on. I’ve written some more in the other topic about why that is and how you might adapt modules to follow the guidance about having provider configurations only in the root module.
I’m happy to discuss that more over there, if you like: just want to keep all of that discussion in one place, so it’s easier to refer to.
Hi @pdecat,
You can find the current draft of the documentation the upgrade guide is referring to in v0.12-compatible provider requirements, which will be published on terraform.io as part of the final 0.13.0 release.
As you can see there, it won’t be possible to write a cross-compatible module that uses a provider that Terraform 0.12 couldn’t previously install, but for examples like datadog those were not “moved out” of the hashicorp namespace, but were rather not moved into it in the first place: the home of all providers before introduction of the heirarchical addressing scheme was the terraform-providers organization, and so the ones that are not maintained directly by HashiCorp continue to exist there.
You can write a module that depends on the datadog provider by following the guidance in that documentation section, giving something like the following:
terraform {
required_providers {
datadog = {
source = "terraform-providers/datadog"
}
}
}
The terraform 0.13upgrade command knows how to generate the above automatically, so if you go through the recommended upgrade process for each of your modules then you shouldn’t need to do anything additional.
This works because most of the 0.12.x releases understand that new required_providers syntax but just ignore the source part and use the old technique for finding the source location of the provider. That was done in anticipation of this transition.
Hi @slonokot,
The for expression you found is indeed the way to take the role_arn for each of the module instances. You can write that same expression inline rather than creating a local value for it, if you want:
application_iam_roles = [
for module_instance in module.base_remote_state :
module_instance.role_arn
]
Thanks for the quick response!
Well, I tried adding the source field in required_providersbefore posting here and terraform 0.12.29 rejected it saying it wasn’t supported.
Edit: oops, read that wrong, it was just a warning 
Warning: Provider source not supported in Terraform v0.12
on .terraform/modules/signalfx.signalfx-detectors-caas-kubernetes-workloads/versions.tf line 3, in terraform:
3: signalfx = {
4: source = "terraform-providers/signalfx"
5: }
A source was declared for provider signalfx. Terraform v0.12 does not support
the provider source attribute. It will be ignored.
9 posts were split to a new topic: Dynamically switching between different providers
A post was split to a new topic: Terraform v0.13 discovery of providers in the local filesystem