Community Note
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
- Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
- If you are interested in working on this issue or have submitted a pull request, please leave a comment. If the issue is assigned to the "modular-magician" user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If the issue is assigned to a user, that user is claiming responsibility for the issue. If the issue is assigned to "hashibot", a community member has claimed the issue already.
Description
When you create a Dialogflow CX Agent, it automatically creates a DF CX Flow for you; this is the Agent.startFlow; the API docs say "A start flow will be automatically created when the agent is created, and can only be deleted by deleting the agent". Other docs say it'll have "the following flow ID: 00000000-0000-0000-0000-000000000000" i.e. Agent.startFlow will always be projects/<project-id>/locations/<location-id>/agents/<agent-id>/flows/00000000-0000-0000-0000-000000000000
You cannot easily manage this resource in terraform. You have to import it. You know what the terraform import command would look like. You can easily write the import block:
resource "google_dialogflow_cx_agent" "agent" {
...
}
import {
id = google_dialogflow_cx_agent.agent.start_flow
to = google_dialogflow_cx_flow.default-start-flow
}
resource "google_dialogflow_cx_flow" "default-start-flow" {
parent = google_dialogflow_cx_agent.agent.id
...
}
UNFORTUNATELY, the import block is still pretty dumb; if you write that completely reasonable looking terraform, it errors with
│ Error: Invalid import id argument
│
│ on main.tf line 209, in import:
│ 209: id = google_dialogflow_cx_agent.agent.start_flow
│
│ The import block "id" argument depends on resource attributes that cannot be determined until apply, so Terraform cannot plan to import this resource.
i.e. there's no one-terraform apply way of managing an Agent + the default start flow. You have to break it into two steps (step 1: apply the agent creation; step 2: import). That's annoying.
Also, even if terraform improves the import block, you're not allowed to delete a default start flow; GCP gives you an error. That's annoying too if you want to remove resources or stop managing stuff.
Same situation for the Default welcome intent, just swap out "intent" for "flow" above.
I wasn't able to find a feature request against terraform itself for improving the import block behavior.
New or Affected Resource(s)
- google_dialogflow_cx_flow
- google_dialogflow_cx_intent
resource "google_dialogflow_cx_flow" "default-start-flow" {
is_default_start_flow = true
...
}
resource "google_dialogflow_cx_intent" "default-welcome-intent" {
is_default_welcome_intent = true
...
}
Make the is_defult_X fields immutable + not written to the REST API. If they're true, prevent the resource from being created (http POST) or destroyed (http DELETE) and just set the ID to {parent}/flows/00000000-0000-0000-0000-000000000000 or {parent}/intents/00000000-0000-0000-0000-000000000000.
resource "google_dialogflow_cx_flow" "default-start-flow" {
name = "00000000-0000-0000-0000-000000000000"
...
}
resource "google_dialogflow_cx_intent" "default-welcome-intent" {
name = "00000000-0000-0000-0000-000000000000"
...
}
Make the name property settable, immutable, and default-from-API. If it's set by the user, PATCH instead of POST and prevent DELETEs.
Potential Terraform Configuration (not implemented yet)
resource "google_dialogflow_cx_default_start_flow" "default-start-flow" {
...
}
resource "google_dialogflow_cx_default_welcome_intent" "default-welcome-intent" {
...
}
resource "google_dialogflow_cx_default_negative_intent" "default-negative-intent" {
...
}
Make three new resources that are hyper-specialized copy-pastes of the existing flow + intent resources. Don't let them POST or DELETE cloud resources.
References
b/307909166
Community Note
Description
When you create a Dialogflow CX Agent, it automatically creates a DF CX Flow for you; this is the
Agent.startFlow; the API docs say "A start flow will be automatically created when the agent is created, and can only be deleted by deleting the agent". Other docs say it'll have "the following flow ID:00000000-0000-0000-0000-000000000000" i.e. Agent.startFlow will always beprojects/<project-id>/locations/<location-id>/agents/<agent-id>/flows/00000000-0000-0000-0000-000000000000You cannot easily manage this resource in terraform. You have to import it. You know what the
terraform importcommand would look like. You can easily write theimportblock:UNFORTUNATELY, the
importblock is still pretty dumb; if you write that completely reasonable looking terraform, it errors withi.e. there's no one-
terraform applyway of managing an Agent + the default start flow. You have to break it into two steps (step 1: apply the agent creation; step 2: import). That's annoying.Also, even if terraform improves the
importblock, you're not allowed to delete a default start flow; GCP gives you an error. That's annoying too if you want to remove resources or stop managing stuff.Same situation for the Default welcome intent, just swap out "intent" for "flow" above.
I wasn't able to find a feature request against terraform itself for improving the
importblock behavior.New or Affected Resource(s)
Potential Terraform Configuration (implemented in GoogleCloudPlatform/magic-modules#9336)
Make the
is_defult_Xfields immutable + not written to the REST API. If they'retrue, prevent the resource from being created (http POST) or destroyed (http DELETE) and just set the ID to{parent}/flows/00000000-0000-0000-0000-000000000000or{parent}/intents/00000000-0000-0000-0000-000000000000.Potential Terraform Configuration (implemented in GoogleCloudPlatform/magic-modules#9359)
Make the
nameproperty settable, immutable, and default-from-API. If it's set by the user, PATCH instead of POST and prevent DELETEs.Potential Terraform Configuration (not implemented yet)
Make three new resources that are hyper-specialized copy-pastes of the existing
flow+intentresources. Don't let them POST or DELETE cloud resources.References
b/307909166