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

Add app engine domain mappings resource #2216

Merged

Conversation

megan07
Copy link
Contributor

@megan07 megan07 commented Aug 20, 2019

Fixes hashicorp/terraform-provider-google#3204

Add the new resource google_appengine_domain_mapping

The test creates the appropriate resource, however, I wasn't able to get the certificate provisioned. I wasn't able to get it provisioned in the console either (so it may be a permissions issue?). Not sure if that will be a requirement in the tests or not.

Release Note for Downstream PRs (will be copied)

Add the new resource `google_appengine_domain_mapping`

@megan07 megan07 force-pushed the megan_domain_mappings branch from 653a7d3 to aec3970 Compare August 21, 2019 15:54
@modular-magician
Copy link
Collaborator

Hi! I'm the modular magician, I work on Magic Modules.
This PR seems not to have generated downstream PRs before, as of aec397020ca70990b179086d59c3fb093dfc2522.

Pull request statuses

No diff detected in Ansible.
No diff detected in Inspec.

New Pull Requests

I built this PR into one or more new PRs on other repositories, and when those are closed, this PR will also be merged and closed.
depends: hashicorp/terraform-provider-google-beta#1079
depends: GoogleCloudPlatform/terraform-google-conversion#175
depends: hashicorp/terraform-provider-google#4310

Copy link
Contributor

@danawillow danawillow left a comment

Choose a reason for hiding this comment

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

The test passed (https://ci-oss.hashicorp.engineering/viewLog.html?buildId=70373&tab=buildResultsDiv&buildTypeId=GoogleCloud_ProviderGoogleCloudGoogleProject) so I wouldn't worry too much about the certificate thing.

Don't forget to add the resource to google.erb as well!

I'm also going to go ahead and add a changelog label to this PR because I don't think it'll get auto-changelogged without one

description: |
A domain serving an App Engine application.
base_url: 'apps/{{project}}/domainMappings'
self_link: 'apps/{{project}}/domainMappings/{{domain_name}}'
Copy link
Contributor

Choose a reason for hiding this comment

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

Since domain_name is a TF override, I think instead you'll want to make that {{id}} and then override it in TF, or if it works, you might just be able to replace the whole string with {{name}}

By default, overrides are rejected.
url_param_only: true
values:
- :UNSPECIFIED_DOMAIN_OVERRIDE_STRATEGY
Copy link
Contributor

Choose a reason for hiding this comment

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

It's probably not worth allowing people to set this value (and all the other UNSPECIFIED enum values)

- !ruby/object:Api::Type::Enum
name: 'sslManagementType'
description: |
SSL management type for this domain. If `AUTOMATIC`, a managed certificate is automatically provisioned.
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this mean that certificateId should be computed?

Copy link
Contributor Author

@megan07 megan07 Aug 21, 2019

Choose a reason for hiding this comment

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

I believe so. That was one of the things I was trying to test, because as I was testing this I never actually saw certificateId be populated, but it seems like it should be. But I was getting that provisioning error, so I assumed that's why. But if this is set to MANUAL then it won't be computed.

- DELETING
- ERROR
- UPDATING
- :STATE_UNSPECIFIED
Copy link
Contributor

Choose a reason for hiding this comment

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

This change looks good, but not relevant to this resource. Can it be made separately?

@@ -0,0 +1,15 @@
// While the domain mapping is setting up the certificate id, GET returns a field
// `pendingManagedCertificateId`, which will eventually be empty when `certificateID`
Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't that field output-only? If so, what happens if you get rid of the diffsuppress (since those should only be needed for fields that are user-specified)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've removed this now, however, one concern I have, and part of the reason I wanted to test it with a generated certificate, is because I think pendingManagedCertificateId will go from computed to empty (which is fine), but I'm guessing that certificateId will go from empty to computed, in which case I'm guessing we might see a diff.

DomainMapping: !ruby/object:Overrides::Terraform::ResourceOverride
id_format: "{{domain_name}}"
import_format: ["{{domain_name}}"]
examples:
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you also add a handwritten test that tests update?

@modular-magician
Copy link
Collaborator

Hi! I'm the modular magician, I work on Magic Modules.
I see that this PR has already had some downstream PRs generated. Any open downstreams are already updated to your most recent commit, ffe36d1.

Pull request statuses

terraform-provider-google-beta already has an open PR.
terraform-google-conversion already has an open PR.
terraform-provider-google already has an open PR.
No diff detected in Inspec.

New Pull Requests

I built this PR into one or more new PRs on other repositories, and when those are closed, this PR will also be merged and closed.
depends: modular-magician/ansible#367

@modular-magician
Copy link
Collaborator

Hi! I'm the modular magician, I work on Magic Modules.
I see that this PR has already had some downstream PRs generated. Any open downstreams are already updated to your most recent commit, 034cf41.

Pull request statuses

terraform-provider-google-beta already has an open PR.
terraform-google-conversion already has an open PR.
terraform-provider-google already has an open PR.
No diff detected in Ansible.
No diff detected in Inspec.

New Pull Requests

I didn't open any new pull requests because of this PR.

@megan07 megan07 requested a review from danawillow August 26, 2019 14:55
@khanali21
Copy link
Contributor

@rileykarson @megan07 would you know if anyone is working on the dispatch url for appengine service?

@rileykarson
Copy link
Member

Since there's no issue in https://github.com/terraform-providers/terraform-provider-google/issues, I'd imagine there is not.

# limitations under the License.
-%>
updateMask := []string{}
if d.HasChange("ssl_settings") {
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this file mean that update_mask_fields doesn't quite work for this resource? If so, could you add a comment explaining why? (probably best to stick it here and in terraform.yaml)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was not aware that field existed - and it worked! So I changed it to that :). Thanks!

resource.Test(t, resource.TestCase{
PreCheck: func() { testAccPreCheck(t) },
Providers: testAccProviders,
CheckDestroy: testAccCheckBigtableAppProfileDestroy,
Copy link
Contributor

Choose a reason for hiding this comment

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

You probably want a different destroy

@megan07 megan07 force-pushed the megan_domain_mappings branch from 034cf41 to 2054c13 Compare September 6, 2019 14:38
@modular-magician
Copy link
Collaborator

Hi! I'm the modular magician, I work on Magic Modules.
I see that this PR has already had some downstream PRs generated. Any open downstreams are already updated to your most recent commit, 2054c13.

Pull request statuses

terraform-provider-google-beta already has an open PR.
terraform-google-conversion already has an open PR.
terraform-provider-google already has an open PR.
No diff detected in Ansible.
No diff detected in Inspec.

New Pull Requests

I didn't open any new pull requests because of this PR.

@megan07 megan07 force-pushed the megan_domain_mappings branch from 2054c13 to 5277a87 Compare September 6, 2019 16:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

App Engine domain mapping
6 participants