Call to function "zipmap" failed: number of keys (2) does not match number of values (3). about terraform-google-cloud-storage HOT 9 CLOSED

Yup, it's a know issue, workaround is to temporarily comment out the outputs until the new resource is in. Will probably be fixed in a future release, once we switch to using foreach instead of count.

from terraform-google-cloud-storage.

So the list ordering issue is also known? The one that if you remove one of the names, the subsequence buckets will be replaced.

from terraform-google-cloud-storage.

Absolutely, that's a Terraform limitation using count with resources, and will go away once we switch to foreach.

from terraform-google-cloud-storage.

Any ongoing effort with the change? If not, I might be able to contribute to this.

from terraform-google-cloud-storage.

We did not start yet, as the plan was to do complete 0.12 migration for all the mutiple-resource modules, then switch them all to foreach. Migration is done, we just need to find the time to tackle this. If you feel like starting, by all means that is more than welcome. :)

from terraform-google-cloud-storage.

FYI I'm not sure this is directly related to foreach vs. count. It might fix it though.

from terraform-google-cloud-storage.

Just to provide some additional context, this bug has the potential to be quite severe, requiring modifications to Terraform state and manual deletion of buckets it creates to enable Terraform Plans to run in a previously functional configuration.

from terraform-google-cloud-storage.

It shouldn't require manual deletion. There's a simple fix anyways.

from terraform-google-cloud-storage.

@Jberlinsky The fix is trivial, take a look at #23.

from terraform-google-cloud-storage.