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 google_app_engine_application resource. #2147

Merged
merged 4 commits into from
Oct 3, 2018
Merged

Conversation

paddycarver
Copy link
Contributor

Deprecate the app_engine sub-block of google_project, and create a
google_app_engine_application resource instead. Also, add some tests for
its behaviour, as well as some documentation for it.

Note that this is largely an implementation of the ideas discussed in
#2118, except we're not using CustomizeDiff to reject deletions without
our special flag set, because CustomizeDiff apparently doesn't run on
Delete. Who knew? This leaves us rejecting the deletion at apply time,
which is less than ideal, but the only other option I see is to silently
not delete the resource, and that's... not ideal, either.

This also stops the app_engine sub-block on google_project from forcing
new when it's removed, and sets it to computed, so users can safely move
from using the sub-block to using the resource without state surgery or
deleting their entire project. This does mean it's impossible to delete
an App Engine application from a sub-block now, but seeing as that was
the same situation before, and we just papered over it by making the
project recreate itself in that situation, and people Were Not Fans of
that, I'm considering that an acceptable casualty.

Deprecate the app_engine sub-block of google_project, and create a
google_app_engine_application resource instead. Also, add some tests for
its behaviour, as well as some documentation for it.

Note that this is largely an implementation of the ideas discussed in
 #2118, except we're not using CustomizeDiff to reject deletions without
our special flag set, because CustomizeDiff apparently doesn't run on
Delete. Who knew? This leaves us rejecting the deletion at apply time,
which is less than ideal, but the only other option I see is to silently
not delete the resource, and that's... not ideal, either.

This also stops the app_engine sub-block on google_project from forcing
new when it's removed, and sets it to computed, so users can safely move
from using the sub-block to using the resource without state surgery or
deleting their entire project. This does mean it's impossible to delete
an App Engine application from a sub-block now, but seeing as that was
the same situation before, and we just papered over it by making the
project recreate itself in that situation, and people Were Not Fans of
that, I'm considering that an acceptable casualty.
}
}

func appEngineApplicationURLDispatchRuleResource() *schema.Resource {
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: any reason these are funcs and not vars?

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 it's conventional/how I learned how to do it? If I had to guess, it's to keep important mutable state out of the global scope (the Schema is a pointer, someone mutating it will have a big effect on everyone else, probably unintentionally) but I could be very wrong about that.

pid := d.Id()

app, err := config.clientAppEngine.Apps.Get(pid).Do()
if err != nil && !isGoogleApiErrorWithCode(err, 404) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think since it's its own resource now, you can do a regular handleNotFoundError call

}

func resourceAppEngineApplicationDelete(d *schema.ResourceData, meta interface{}) error {
log.Println("[DEBUG] App Engine applications cannot be destroyed once created. The project must be deleted to delete the application.")
Copy link
Contributor

Choose a reason for hiding this comment

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

it doesn't really matter since from my memory log levels only apply to tf core and not the providers, but if they did make a difference, i would say this should be a WARNING like we do for KmsKeyRing

if err != nil {
return err
}
app.Id = project
Copy link
Contributor

Choose a reason for hiding this comment

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

this line can be removed, it's handled in the expander

if len(blocks) < 1 {
return nil, nil
}
if len(blocks) > 1 {
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 already a plan-time check, so no need to check it again

Optional: true,
Computed: true,
},
"location_id": &schema.Schema{
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this updatable? It's not in the updateMask if 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.

Nope. I guess I'll make it ForceNew, even though that will cause a problem if people do update it? I'm not 100% sure what a good user experience is in this case. I guess I could customize diff to reject this, at least.

Allows management of an App Engine application.
---

# google\_app_engine_application
Copy link
Contributor

Choose a reason for hiding this comment

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

I would assume we either need slashes before all underscores or before no underscores


```hcl
resource "google_project" "my_project" {
name = "My Project"
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: alignment


resource "google_app_engine_application" "app" {
project = "${google_project.my_project.project_id}"
location_id = "us-central'
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: too many spaces after location_id


* `auth_domain` - (Optional) The domain to authenticate users with when using App Engine's User API.

* `serving_status` - (Optional) The serving status of the app. Note that this can't be updated at the moment.
Copy link
Contributor

Choose a reason for hiding this comment

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

the code makes it look like it can, is this sentence wrong or should the code be updated?

@paddycarver
Copy link
Contributor Author

@danawillow ready for round two, I think!

@paddycarver paddycarver added this to the 1.19.0 milestone Oct 2, 2018
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.

Our migration story is going to be import I assume, right?

func appEngineApplicationLocationIDCustomizeDiff(d *schema.ResourceDiff, meta interface{}) error {
old, new := d.GetChange("location_id")
if old != "" && old != new {
return fmt.Errorf("Cannot change location_id once the resource is created.")
Copy link
Contributor

Choose a reason for hiding this comment

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

Oh clever! Let's do this for project too.

// Wait for the operation to complete
waitErr := appEngineOperationWait(config.clientAppEngine, op, project, "App Engine app to create")
if waitErr != nil {
return waitErr
Copy link
Contributor

Choose a reason for hiding this comment

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

Either we need to d.SetId("") here or move the d.SetId(project) call to after this. I'd recommend the first just for consistency with the rest of the resources.

@paddycarver
Copy link
Contributor Author

Our migration story is going to be import I assume, right?

Yup!

  1. Import the app.
  2. Add the app to your config.
  3. Remove the app_engine sub-block from google_project. Removing it won't ForceNew now.

@paddycarver paddycarver merged commit 69589e5 into master Oct 3, 2018
@paultyng paultyng deleted the paddy_new_appengine branch October 29, 2018 19:27
chrisst pushed a commit to chrisst/terraform-provider-google that referenced this pull request Nov 9, 2018
…appengine

Add google_app_engine_application resource.
@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.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants