Add project_number field to google_storage_bucket resource and datasource, enable providing project argument to data source

[SarahFrench]

Closes hashicorp/terraform-provider-google#17166

This PR aims to address an edge case where users do not want to give the identity/service account used by Terraform permissions on the Compute API and want to provision GCS buckets. Previously if a project name was not supplied to the data source via provider defaults then the data source would:

• retrieve information about the bucket from the Storage API, including the project number it's linked to
• call the Compute API to get a human-readable project id for that project number, and use that to populate the project field

By letting users set the project field on the data source they can avoid that call to the Compute API. There is a chance that the project id they supply doesn't match the project number linked to the GCS bucket. This isn't ideal, but was OK'd during triage as it matches the existing behaviour on import.

This PR also adds a new field, project_number, to surface the information returned from the Storage API which is guaranteed to be accurate. This enables users to perform any checks etc to verify the project id and number are a correct pairing.

Release Note Template for Downstream PRs (will be copied)

storage: added `project_number` attribute to `google_storage_bucket` resource and data source

storage: added ability to provide `project` argument to `google_storage_bucket` data source. This will not impact reading the resource's data, instead this helps users avoid calls to the Compute API within the data source.

[modular-magician]

Hi there, I'm the Modular magician. I've detected the following information about your changes:

Diff report

Your PR generated some diffs in downstreams - here they are.

google provider: Diff ( 4 files changed, 85 insertions(+), 7 deletions(-))
google-beta provider: Diff ( 4 files changed, 85 insertions(+), 7 deletions(-))

[modular-magician]

Tests analytics

Total tests: 91
Passed tests: 84
Skipped tests: 6
Affected tests: 1

Click here to see the affected service packages

• storage

Action taken

Found 1 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected tests

TestAccDataSourceGoogleStorageBucket_avoidComputeAPI

Get to know how VCR tests work

[modular-magician]

$\textcolor{green}{\textsf{Tests passed during RECORDING mode:}}$
TestAccDataSourceGoogleStorageBucket_avoidComputeAPI[Debug log]

$\textcolor{green}{\textsf{No issues found for passed tests after REPLAYING rerun.}}$

---

$\textcolor{green}{\textsf{All tests passed!}}$
View the build log or the debug log for each test

[zli82016]

By letting users set the project field on the data source they can avoid that call to the Compute API. There is a chance that the project id they supply doesn't match the project number linked to the GCS bucket. This isn't ideal, but was OK'd during triage as it matches the existing behaviour on import.

Instead of adding the project field to data source, maybe we can consider creating a new function for data source, similar to setStorageBucket, but without the project checking code. It will avoid the incorrect project provided by the users for the data source.

[SarahFrench]

Yeah that's another option & I'm happy to pursue it. That function is trying to cover a lot of scenarios!

I'll probably pick that up next week, as I'm OOO Friday-Monday

[SarahFrench]

Ah, I just thought. A change like that would be a breaking change for all users who are happy with the resource interacting with the Compute API. I'm opening this PR for a small minority of users who don't want Compute API to be used inside this data source but there may be users out there relying on this behaviour

[zli82016]

Ah, I just thought. A change like that would be a breaking change for all users who are happy with the resource interacting with the Compute API. I'm opening this PR for a small minority of users who don't want Compute API to be used inside this data source but there may be users out there relying on this behaviour

I see. I didn't realize that. We can go with the current change. Can we also add note for providing the correct project to the data source documentation ? Thanks.

[modular-magician]

Hi there, I'm the Modular magician. I've detected the following information about your changes:

Diff report

Your PR generated some diffs in downstreams - here they are.

google provider: Diff ( 5 files changed, 87 insertions(+), 7 deletions(-))
google-beta provider: Diff ( 5 files changed, 87 insertions(+), 7 deletions(-))

[zli82016]

LGTM if all of the checks pass.

[modular-magician]

Tests analytics

Total tests: 91
Passed tests: 85
Skipped tests: 6
Affected tests: 0

Click here to see the affected service packages

• storage

$\textcolor{green}{\textsf{All tests passed!}}$
View the build log

[SarahFrench]

Thanks!