-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Conversation
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 { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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.") |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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{ |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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' |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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?
@danawillow ready for round two, I think! |
There was a problem hiding this 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.") |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
Yup!
|
…appengine Add google_app_engine_application resource.
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! |
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.