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

Make App Engine applications updatable #1621

Merged
merged 8 commits into from
Jun 11, 2018
Merged

Conversation

paddycarver
Copy link
Contributor

No longer ForceNew on every little change to an App Engine application. Now adding an App Engine application to a project doesn't force a new project, only removing an application from a project forces a new project. Also, updating the location_id forces a new project, but all other fields can be updated in place.

This depends on #1620 and should only be merged after that is.

No longer ForceNew when adding an App Engine application to a project,
when modifying the auth domain, modifying the serving status, or
modifying the feature settings.
@paddycarver paddycarver requested review from danawillow and a team June 7, 2018 23:11
@@ -103,6 +103,7 @@ func resourceGoogleProject() *schema.Resource {

func appEngineResource() *schema.Resource {
return &schema.Resource{
CustomizeDiff: resourceGoogleProjectAppEngineCustomizeDiff,
Schema: map[string]*schema.Schema{
"name": &schema.Schema{
Type: schema.TypeString,
Copy link
Contributor

Choose a reason for hiding this comment

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

Not actually related to this change, but can you order the properties in Required -> Optional -> Computed order? I'm a big fan of that to make it easy to immediately see which fields are settable.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍

return nil
}

func resourceGoogleProjectAppEngineCustomizeDiff(diff *schema.ResourceDiff, meta interface{}) error {
Copy link
Contributor

Choose a reason for hiding this comment

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

This can probably be removed

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oops, sorry, this is a remnant of my futzing around with customize diff -_-

log.Printf("[DEBUG] Updated App Engine App")
}
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

May as well d.SetPartial here in case someone comes and adds a new HasChange after this

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍

Steps: []resource.TestStep{
{
Config: testAccProject_appEngineNoApp(pid, org),
Check: resource.ComposeTestCheckFunc(
Copy link
Contributor

Choose a reason for hiding this comment

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

If you want to keep the checks I won't tell you no, but they aren't necessary if you check by importing

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 think in this case import wouldn't actually check them, because they're computed fields not set in the config, so I believe without the checks, if the fields just aren't being set, ImportStateVerify won't complain. Because (from what I understand) ImportStateVerify just creates a new, empty state, imports the resource again, and checks it against the state from creating the resource. If there was a bug where these weren't being set, in both cases it would have them not set, so ImportStateVerify would think that's fine. And because they're computed and not config fields, there'd be no diff.

Copy link
Contributor

Choose a reason for hiding this comment

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

Cool, makes sense! Regardless, you can still take out testAccCheckGoogleProjectExists

func testAccProject_appEngineUpdate(pid, org string) string {
return fmt.Sprintf(`
resource "google_project" "acceptance" {
project_id = "%s"
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: can you align the =s here? (as if you were to run terraform fmt)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍

@@ -402,6 +459,15 @@ resource "google_folder" "folder1" {
`, pid, projectName, folderName, org)
}

func testAccProject_appEngineNoApp(pid, org string) string {
Copy link
Contributor

Choose a reason for hiding this comment

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

this is pretty much identical to testAccProject_create (which lives in resource_google_project_iam_policy_test.go) if you wanted to reuse that (a few other resources are doing so)

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 have a weakly-held opinion that it's better to have the configs for semantically different things separated, even if the implementation ends up looking the same, to minimize unintended consequences of changes. But if you feel strongly about it, I'm happy to change this.

Copy link
Contributor

Choose a reason for hiding this comment

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

Cool that's fine!

@paddycarver
Copy link
Contributor Author

Think I addressed all the feedback here. :)

@paddycarver paddycarver merged commit 430b735 into master Jun 11, 2018
@paultyng paultyng deleted the paddy_app_engine_app branch October 29, 2018 19:28
@ghost
Copy link

ghost commented Nov 16, 2018

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 👉 hashibot-feedback@hashicorp.com. Thanks!

@ghost ghost locked and limited conversation to collaborators Nov 16, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants