Add google_app_engine_application resource.
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.
2018-10-02 09:59:17 +00:00
|
|
|
---
|
|
|
|
|
layout: "google"
|
|
|
|
|
page_title: "Google: google_app_engine_application"
|
|
|
|
|
sidebar_current: "docs-google-app-engine-application"
|
|
|
|
|
description: |-
|
|
|
|
|
Allows management of an App Engine application.
|
|
|
|
|
---
|
|
|
|
|
|
2018-10-02 23:34:34 +00:00
|
|
|
# google_app_engine_application
|
Add google_app_engine_application resource.
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.
2018-10-02 09:59:17 +00:00
|
|
|
|
|
|
|
|
Allows creation and management of an App Engine application.
|
|
|
|
|
|
|
|
|
|
~> App Engine applications cannot be deleted once they're created; you have to delete the
|
2018-10-02 21:15:31 +00:00
|
|
|
entire project to delete the application. Terraform will report the application has been
|
|
|
|
|
successfully deleted; this is a limitation of Terraform, and will go away in the future.
|
|
|
|
|
Terraform is not able to delete App Engine applications.
|
Add google_app_engine_application resource.
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.
2018-10-02 09:59:17 +00:00
|
|
|
|
|
|
|
|
## Example Usage
|
|
|
|
|
|
|
|
|
|
```hcl
|
|
|
|
|
resource "google_project" "my_project" {
|
2018-10-02 23:34:34 +00:00
|
|
|
name = "My Project"
|
Add google_app_engine_application resource.
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.
2018-10-02 09:59:17 +00:00
|
|
|
project_id = "your-project-id"
|
|
|
|
|
org_id = "1234567"
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
resource "google_app_engine_application" "app" {
|
2018-10-02 23:34:34 +00:00
|
|
|
project = "${google_project.my_project.project_id}"
|
2019-03-07 16:50:12 +00:00
|
|
|
location_id = "us-central"
|
Add google_app_engine_application resource.
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.
2018-10-02 09:59:17 +00:00
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
## Argument Reference
|
|
|
|
|
|
|
|
|
|
The following arguments are supported:
|
|
|
|
|
|
|
|
|
|
* `location_id` - (Required) The [location](https://cloud.google.com/appengine/docs/locations)
|
|
|
|
|
to serve the app from.
|
|
|
|
|
|
|
|
|
|
* `auth_domain` - (Optional) The domain to authenticate users with when using App Engine's User API.
|
|
|
|
|
|
2018-10-02 23:34:34 +00:00
|
|
|
* `serving_status` - (Optional) The serving status of the app.
|
Add google_app_engine_application resource.
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.
2018-10-02 09:59:17 +00:00
|
|
|
|
|
|
|
|
* `feature_settings` - (Optional) A block of optional settings to configure specific App Engine features:
|
|
|
|
|
|
|
|
|
|
* `split_health_checks` - (Optional) Set to false to use the legacy health check instead of the readiness
|
|
|
|
|
and liveness checks.
|
|
|
|
|
|
|
|
|
|
## Attributes Reference
|
|
|
|
|
|
|
|
|
|
In addition to the arguments listed above, the following computed attributes are
|
|
|
|
|
exported:
|
|
|
|
|
|
|
|
|
|
* `name` - Unique name of the app, usually `apps/{PROJECT_ID}`
|
|
|
|
|
|
|
|
|
|
* `url_dispatch_rule` - A list of dispatch rule blocks. Each block has a `domain`, `path`, and `service` field.
|
|
|
|
|
|
|
|
|
|
* `code_bucket` - The GCS bucket code is being stored in for this app.
|
|
|
|
|
|
|
|
|
|
* `default_hostname` - The default hostname for this app.
|
|
|
|
|
|
|
|
|
|
* `default_bucket` - The GCS bucket content is being stored in for this app.
|
|
|
|
|
|
|
|
|
|
* `gcr_domain` - The GCR domain used for storing managed Docker images for this app.
|
|
|
|
|
|
|
|
|
|
## Import
|
|
|
|
|
|
|
|
|
|
Applications can be imported using the ID of the project the application belongs to, e.g.
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
$ terraform import google_app_engine_application.app your-project-id
|
|
|
|
|
```
|