Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle email-less services in google_project_service_identity #6192

Conversation

SarahFrench
Copy link
Collaborator

@SarahFrench SarahFrench commented Jun 30, 2022

Description

Closes hashicorp/terraform-provider-google#10367

This PR changes the google_project_service_identity resource to handle scenarios when it successfully creates a service identity for a given Google API via generateServiceIdentity but the response doesn't contain the service identity's email. Now email will only be set if the response contains an email.

The downside is that if the email isn't returned by the API, user won't know until they try to reference the email attribute elsewhere

Examples of the endpoint succeeding & returning an email, succeeding but not returning an email, and erroring:

$ gcloud beta services identity create --service=containerscanning.googleapis.com                    
Service identity created: service-XXXXXXXXXX@gcp-sa-containerscanning.iam.gserviceaccount.com

$ gcloud beta services identity create --service=logging.googleapis.com          
Service identity created

$ gcloud beta services identity create --service=stackdriverprovisioning.googleapis.com
ERROR: (gcloud.beta.services.identity.create) INVALID_ARGUMENT: Service stackdriverprovisioning.googleapis.com has not been configured for service identities.

Checklist

If this PR is for Terraform, I acknowledge that I have:

  • Searched through the issue tracker for an open issue that this either resolves or contributes to, commented on it to claim it, and written "fixes {url}" or "part of {url}" in this PR description. If there were no relevant open issues, I opened one and commented that I would like to work on it (not necessary for very small changes).
  • Generated Terraform, and ran make test and make lint to ensure it passes unit and linter tests.
  • Ensured that all new fields I added that can be set by a user appear in at least one example (for generated resources) or third_party test (for handwritten resources or update tests).
  • Ran relevant acceptance tests (If the acceptance tests do not yet pass or you are unable to run them, please let your reviewer know).
  • Read the Release Notes Guide before writing my release note below.

Release Note Template for Downstream PRs (will be copied)

serviceusage: fixed an issue where `google_project_service_identity` didn't handle service identities without emails correctly (beta)

@modular-magician
Copy link
Collaborator

Oops! It looks like you're using an unknown release-note type in your changelog entries:

  • REPLACEME

Please only use the types listed in https://github.com/GoogleCloudPlatform/magic-modules/blob/master/.ci/RELEASE_NOTES_GUIDE.md.

@modular-magician
Copy link
Collaborator

Hello! I am a robot who works on Magic Modules PRs.

I've detected that you're a community contributor. @rileykarson, a repository maintainer, has been assigned to assist you and help review your changes.

❓ First time contributing? Click here for more details

Your assigned reviewer will help review your code by:

  • Ensuring it's backwards compatible, covers common error cases, etc.
  • Summarizing the change into a user-facing changelog note.
  • Passes tests, either our "VCR" suite, a set of presubmit tests, or with manual test runs.

You can help make sure that review is quick by running local tests and ensuring they're passing in between each push you make to your PR's branch. Also, try to leave a comment with each push you make, as pushes generally don't generate emails.

If your reviewer doesn't get back to you within a week after your most recent change, please feel free to leave a comment on the issue asking them to take a look! In the absence of a dedicated review dashboard most maintainers manage their pending reviews through email, and those will sometimes get lost in their inbox.


@SarahFrench
Copy link
Collaborator Author

Testing

There aren't any existing acceptance tests to add to (makes sense as there aren't ways to delete this resource once it's made) but I did test the change manually using this configuration and ENVs to set the project etc:

provider "google-beta" {
}

resource "google_project_service_identity" "containerscanning" {
  provider = google-beta
  service = "containerscanning.googleapis.com"
}

resource "google_project_service_identity" "logging" {
  provider = google-beta
  service = "logging.googleapis.com"
}

output "logging-email" {
  value = google_project_service_identity.logging.email
}

output "containerscanning-email" {
  value = google_project_service_identity.containerscanning.email
}

With this PR the configuration runs without error, but as expected the output logging-email doesn't get a value and is not added to outputs in state.

I'm happy to add an acceptance test if that'd be preferred!

@modular-magician
Copy link
Collaborator

Hi! I'm the modular magician. Your PR generated some diffs in downstreams - here they are.

Diff report:

Terraform Beta: Diff ( 1 file changed, 11 insertions(+), 10 deletions(-))

@modular-magician
Copy link
Collaborator

Tests analytics

Total tests: 2065
Passed tests 1837
Skipped tests: 226
Failed tests: 2

Action taken

Triggering VCR tests in RECORDING mode for the tests that failed during VCR. Click here to see the failed tests TestAccPrivatecaCertificateAuthority_subordinateCaActivatedByFirstPartyIssuerOnCreation|TestAccPrivatecaCertificateAuthority_privatecaCertificateAuthoritySubordinateExample

@modular-magician
Copy link
Collaborator

Tests passed during RECORDING mode:
TestAccPrivatecaCertificateAuthority_privatecaCertificateAuthoritySubordinateExample[view]
TestAccPrivatecaCertificateAuthority_subordinateCaActivatedByFirstPartyIssuerOnCreation[view]

All tests passed
View the build log or the debug log for each test

@rileykarson rileykarson changed the title Make email an optional field in google_project_service_identity Handle email-less services in google_project_service_identity Jun 30, 2022
Copy link
Member

@rileykarson rileykarson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, yeah, I don't think there's a very reasonable test to write.

Retitled the changelog notes + title, mostly because I misread "optional" as making the field configurable initially.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

"google_project_service_identity" should handle an empty ServiceIdentity
3 participants