Hello,
We just upgraded our terraform google provider version to 5.6.0 then to 5.7.0, In both of these versions there is an issue where when we try to create a new environment from scratch, It gives an error in Terraform plan:-
**Error: projects/dh-pnp-infra-dev-93516/regions/us-east1/subnetworks/pnp-test-pnp-subnet not found with module.base.module.maasmdaas.module.unmanaged-instance.data.google_compute_subnetwork.default, **
**Error on .terraform/modules/base.maasmdaas.unmanaged-instance/registry/services/windows-instance/csr-win-unmanaged-instance/instance_from_********late.tf line 41, in data “google_compute_subnetwork” “default”: ** Error
** 41: data “google_compute_subnetwork” “default” { ** The remote script failed with exit code 1
The problem is that resource is only created in the same module so terraform plan failing is not a valid case obviously subnet will not be present because it’s not created yet as it gets created in same module, so why terraform plan trying to access the resource, earlier terraform plan is not supposed to check if the resource is present or not but in gcp google provider version 5.6.0 & 5.7.0 it is trying and failing even before apply, this is kind of a deadlock for us in new deployments.
This issue we only faced in in 5.x series provider and in 4.84.0 there are no issues like this.
I can’t say exactly why this only started failing after the provider upgrade with only the information provided, but perhaps there was a bug in the older provider which caused the data source read to be delayed for some reason, allowing it to show up after the resource was created.
You should however not be using a data source and a managed resource to represent the same object within a single configuration. The behavior you describe is the expected outcome, because data source are intended to be read as early as possible during the plan. If there is some reason to use a data source too (usually as part of a 3rtd party module which you cannot fix, or to work around a bug in the provider), then you can use depends_on in the data source to ensure it can’t be read until all dependency changes have been applied.
so in the first line you can see it checks if the subnet exists, question is should plan be chckeing that?
Below is the resource(for which we are getting not exist error) that was created in the a module which calls a remote module, that remote module has the data source in it.
The data source is present in the remote module so I can’t really add depends_on on that but however depends_on is aready present on the module by which I am calling the remote module (which has the data source). So in that way dependency is defined.
So yeah I can be said that this data source and the subnet in created in same execution.
But We’re only sending name of subnetwork that will be created(in first image), So that name of subnetwork is transferred to the data block below.
I mean why terraform “plan” will fail in that case, plan is not supposed to check if the resource is available or not, It should show the expected creation. Obviously dependent resource in the same module will get created in apply. only started getting in 5.x series provider of google where plan format is also changed(I can see some changes in how plan is displayed).
it’s more helpful to put the text of the config and output in the post, rather than picture of text.
While you have defined depends_on in the "authzn" module block, the module name in the error does not match the configuration you’ve shown. Are you certain the failure is from the same module?
The plan is checking only what the configuration directs it to check, so if there is a data source it will be read during plan unless prevented by a dependency. If the data source is looking for something which does not yet exist, it’s going to fail to read.
It does not sound relevant to the issue you are having now, but using depends_on in a module block when there are data sources involved can cause other problems when the data source does need to be read during plan, so I would suggest trying to refactor this when possible.
I’ve used depends_on on “authzn” module because this module further calls 2 more child modules, both of them have the dependency on that subnet for which we are getting error, and one of them has that data source.