I’m very excited to announce that we will start shipping public Terraform 0.13.0 beta releases on June 3rd. The full release announcement is posted as a GitHub issue, and I’m opening up this discuss post as a place to host community discussions so that the GitHub issue can be used just for announcements.
15 Likes
Hi
Will the Terraform 0.13.0 beta versions be available on Terraform Cloud for remote executions ?
1 Like
Any chance that 0.13.0 will include for a raise() function for proper error handling?
1 Like
Unfortunately this isn’t in scope for 0.13.0.
Are there any plans to get the WinRM provisioner working again with v0.13 or has support for provisioners been abandoned going forward?
The title might be misleading as the issue isn’t with the specific version of Windows and/or PowerShell as its been replicated with Windows Server 2019 / 2016 and Windows Desktop 10. The underlying issue is when deploying multiple Windows VM’s, the WinRM provisioner gets confused and stops working.
Its easily reproducible, create a TF file with 8+ Windows VM’s and do some simple deployments in each by copying a bunch of files into the VM and try to execute them.
This makes using Terraform v0.12+ with Windows pretty much unusable. The only solution thus far has been to revert to Terraform v0.11.14 which works without any issues.
It would be a shame if Terraform abandoned one of its most valuable features - provisioners.
@debovema our options for Terraform Cloud are a little limited. There is a beta flag at the organizational level, which will opt people in to both TFC beta features as well as having beta versions of Terraform CLI available. It’s not widely used right now, but it is available. If you (or anyone else!) are interested, feel free to reach out to me directly at ddreier@hashicorp.com and give me your organizational name, and I’ll make the needed connections to get the org set up for the beta program. We are definitely hoping to have more options in the future, but this is what we’ve got right now.
@dhekimian thanks for asking. I just put a response on that issue to clarify our stance. WinRM file provisioners are supported, and we will fix that issue. I don’t have a timeline for it yet, and cannot commit to fixing it in 0.13.0. I will keep the GitHub issue updated as we know more.
Are there plans to relax the restriction on nested providers in modules used with count or for_each? For providers such as random or null, requiring the top level module to instantiate providers seems like an unfortunate abstraction violation. Even more so given that instantiating the module without a count doesn’t have the restriction.
Example submodule:
provider "random" {}
and a top level
module "sub" {
source = "./submodule"
count = 2
}
This leads to the unfortunate situation
$ terraform apply
Error: Module does not support count
on main.tf line 11, in module "submodule":
11: count = 2
Module "submodule" cannot be used with count because it contains a nested
provider configuration for "random", at sub/main.tf:3,10-18.
This module can be made compatible with count by changing it to receive all of
its provider configurations from the calling module, by using the "providers"
argument in the calling module block.
Taking it a step stranger, using count with a module that doesn’t have any providers but uses modules with providers is allowed.
main.tf
module "submodule" {
source = "./sub"
count = 2
}
sub/main.tf
module "submodule" {
source = "../sub2"
}
sub2/main.tf
provider "null" {}
resource "null_resource" "demo" {
}
terraform apply -auto-approve
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
# module.submodule[0].module.submodule.null_resource.demo will be created
+ resource "null_resource" "demo" {
+ id = (known after apply)
}
# module.submodule[1].module.submodule.null_resource.demo will be created
+ resource "null_resource" "demo" {
+ id = (known after apply)
}
Plan: 2 to add, 0 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
module.submodule[0].module.submodule.null_resource.demo: Creating...
module.submodule[1].module.submodule.null_resource.demo: Creating...
module.submodule[0].module.submodule.null_resource.demo: Creation complete after 0s [id=3699949161487192158]
module.submodule[1].module.submodule.null_resource.demo: Creation complete after 0s [id=8321835071609336736]
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.
3 Likes
Daniel, I sent you an email asking for this to be turned on for my org, but posting the error for TF Cloud here for others.
terraform13 init
Initializing the backend...
Initializing provider plugins...
- Using previously-installed hashicorp/google v3.24.0
- Using previously-installed terraform-providers/google-beta v3.24.0
- terraform.io/builtin/terraform is built in to Terraform
- Using previously-installed -/google v3.24.0
- Finding latest version of -/terraform...
Error: Incompatible provider version
No compatible versions of provider registry.terraform.io/-/terraform were
found.Hi @WillBeebe,
I recognize that problem with the Terraform provider as one that was already reported and fixed, so that issue should be addressed in beta 2.
The underlying issue is that Terraform interpreting incorrectly a reference to the built-in “terraform” provider in your existing state, understanding it instead as a reference to the externally-distributed version used with some old Terraform 0.10 releases and not compatible with Terraform 0.12 or 0.13. The fix will cause it to be correctly understood as referring to the built-in “terraform” provider, whose full address is terraform.io/builtin/terraform and thus doesn’t need to be separately installed.
Oh cool, thanks for the response @apparentlymart ! Sorry for the duplicate.
Hi,
I read on provider sources that the protocol will eventually be published. Could it use a standard OCI registry ?
That would simplify and reduce the number of registries to manage.
Hi @apparentlymart, I have a similar issue for a simple mongodbatlas database user. Without any provider changes or running terraform 0.13upgrade. I get the following errors on a new state file.
Error: Incompatible provider version
No compatible versions of provider registry.terraform.io/hashicorp/terraform
were found.
Error: Failed to install providers
Could not find required providers, but found possible alternatives:
hashicorp/mongodbatlas -> terraform-providers/mongodbatlas
If these suggestions look correct, upgrade your configuration with the
following command:
terraform 0.13upgrade
on running terraform 0.13upgrade, I’m presented with a list of required providers.
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
}
mongodbatlas = {
source = "terraform-providers/mongodbatlas"
}
terraform = {
source = "hashicorp/terraform"
}
}
required_version = ">= 0.13"
}
Running init again produces the same results. Any idea?
Hi @TheComice,
Do you have other modules in your configuration? The required_providers block is module-specific, so you’ll need to make a similar change in the other modules you use too. The team is working on making this produce a better error message to make that clearer, because several people have encountered this situation. You can see more about this in the following GitHub issue:
Thanks @apparentlymart. I’ve added the required_providers block to the referenced modules which deals with the mongodbatlas provider issue. However now I’m left with: -
Error: Incompatible provider version
No compatible versions of provider registry.terraform.io/hashicorp/terraform
were found.
Not understanding why it would need to Finding latest version of hashicorp/terraform... and in the registry.terraform.io directory there is indeed no versions pulled down but the 13 upgrade command did stipulate this should be a required provider: -
terraform = {
source = "hashicorp/terraform"
}
Any additional help would be appreciated.
Hi @TheComice,
I believe there is a known bug in v0.13.0-beta1 (with a fix already in place ready for beta 2) in how terraform init responds when you already have a reference to the built-in Terraform provider in your existing state, but what you’ve encountered here seems a bit different.
Because the terraform provider is built in to Terraform (since 0.10.x), it uses a different addressing scheme than the others. If you want to specify its source address explicitly then this is how to write that one down:
source = "terraform.io/builtin/terraform"
I see in your earlier comment (though I didn’t notice it at the time) that you mentioned that terraform 0.13upgrade had generated the source = "hashicorp/terraform" you showed. Is that right? If so, it seems you’ve found a bug in the upgrade tool where it isn’t correctly handling the special addressing scheme for built-in providers; would you mind opening a bug report about that, so the team can address it? Thanks!
Yes that’s exactly right @apparentlymart. I’ll happily raise a bug.
Now successfully initialises with the above terraform source. Lovely thanks.
I’m looking forward to the new features but we have a hard blocker preventing use 0.13 since it’s taking away our ability to use destroy-time local-exec to avoid leaking secrets into the Terraform state files since that pattern depended on access to zero-dependency locals.
There’s a lengthy upstream issue here:
I had a lengthy discussion with the second level support about this a few months back and the cleanest option we came up with is an external provider which add a lot of fragile code to maintain. For us, the problem would go away if Terraform could track AWS/Google secrets by their version numbers rather than values — basically https://github.com/terraform-providers/terraform-provider-aws/issues/3475 — so we could reference them in our Terraform configuration but never actually access the secret.
Hi,
Thank you for adding for_each support for modules, this seems to be a really useful feature.
We’ve started experimenting with it, but know having issues with nested providers.
Ideally, we’d like to model this situation:
- use
for_eachwith a module to create multiple Kubernetes clusters - inside that module, after cluster creation, use Kubernetes provider and create a few core resources in it
Unfortunately, this seems now not to be possible, as we’re getting:
Module "cluster_create" cannot be used with for_each because it contains a
nested provider configuration for "kubernetes", at
modules\aks\main.tf:29,10-22.
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.
As the number of clusters might be dynamic, I can’t seem to follow the error advice and pass providers block.
Having this ability would be a great feature for us.
I don’t know if that’s the correct place, but if it would help, I can provide full code example for it.
Thank you
@apparentlymart and @danieldreier, I would love to try out but the beta program application is closed per website. Is there any chance to get in now? It’s for third party provider feature