generate compute instance and subnetwork iam

[modular-magician]

Original Author: @danawillow

iap: added support for IAM Conditions to the `google_compute_instance_iam_*` resources (beta provider only)

`google_compute_instance_iam_*` resources now support IAM Conditions (beta provider only). If any conditions had been created out of band before this release, take extra care to ensure they are present in your Terraform config so the provider doesn't try to create new bindings with no conditions. Terraform will show a diff that it is adding the condition to the resource, which is safe to apply.

[david-walker-gfs]

Due to the lack of a changelog entry for this PR, we hit issues. Would be a good idea to add that this is a breaking change to the CHANGELOG...

Our release process always uses the latest version of the providers. This new version changed the subnetwork value in the state file for the google_compute_subnetwork_iam_member resource from a short name to a fully qualified subnet name.

For example:
The old state file has a value of :
<subnet>
The new state file had a value of:
projects/<network>/regions/<region>/subnetworks/<subnet>

Without upgrading the provider, running a plan using the old provider returned the following error:

Error: Error reading Resource "Compute Subnetwork <project>/<region>/projects/<project>/regions/<region>/subnetworks/<subnet>" with IAM Member: Role "roles/compute.networkUser" Member "group:<group>": Error retrieving IAM policy for Compute Subnetwork <project>/<region>/projects/<project>/regions/<region>/subnetworks/<subnet>: googleapi: Error 400: Invalid value 'projects/<project>/regions/<region>/subnetworks/<subnet>'. Values must match the following regular expression: '[a-z](?:[-a-z0-9]{0,61}[a-z0-9])?|[1-9][0-9]{0,19}', invalidParameter

[danawillow]

Hi @david-walker-gfs, thanks for bringing that to my attention! It didn't occur to me that that would be a user-visible change. I'll add that to the CHANGELOG.

Out of curiosity, what does your config look like? Were you interpolating the value of subnetwork in a different resource?

[david-walker-gfs]

Thanks! We had to hardcode the subnetwork as a local since the subnets are handled by our network team and not visible to us directly. I'm working on getting it exposed as an output from their project but we're a little bit from doing that.

[danawillow]

Sure, but this change should have made it possible for you to pass in any value of subnetwork to this resource. As you said, it's the value in state that changed. I also don't quite understand your statement of "without upgrading the provider"- can you clarify what resources are in your config, what you changed (if anything), and whether the error occurs before or after you upgraded the provider to include this change?

[daithi-walker]

The issue was that for us, our Jenkins builds always download the latest minor release of a provider whereas locally, when we run plans, we may not always have the version of the provider that was used by our Jenkins builds. So running a plan locally failed. But not with an useful information. It doesn't look like the tfstate files contain any information about the provider that was used to build it so it might not be possible to throw a warning to the user.

After running a tf init --upgrade, the issues with running a local plans was resolved. Not sure if there's anything you need to do. But having something in the CHANGELOG about it would have helped identify the that something had changed relating to subnetworks.

[danawillow]

Got it. Anyway, CHANGELOG is now up-to-date (and your posts made me realize we hadn't pushed the 3.0.0-beta.1 changelog over to the master branch, so thanks for that too!)

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!