Closed m-kruth closed 2 years ago
@m-kruth thanks for creating an issue!
That's unfortunate that our instructions were not clear enough and it resulted the migration process caused a downtime for existing accounts.
The gotcha is we support 2 configurations now:
# Configure the Confluent Provider
terraform {
required_providers {
confluent = {
source = "confluentinc/confluent"
version = "1.0.0"
}
}
}
# Option #1 when managing multiple clusters in the same Terraform workspace
provider "confluent" {
cloud_api_key = var.confluent_cloud_api_key # optionally use CONFLUENT_CLOUD_API_KEY env var
cloud_api_secret = var.confluent_cloud_api_secret # optionally use CONFLUENT_CLOUD_API_SECRET env var
}
# Option #2 when managing a single cluster in the same Terraform workspace
# See https://github.com/confluentinc/terraform-provider-confluent/tree/master/examples/configurations/managing-single-cluster for more details
provider "confluent" {
cloud_api_key = var.confluent_cloud_api_key # optionally use CONFLUENT_CLOUD_API_KEY env var
cloud_api_secret = var.confluent_cloud_api_secret # optionally use CONFLUENT_CLOUD_API_SECRET env var
kafka_rest_endpoint = var.kafka_rest_endpoint # optionally use KAFKA_REST_ENDPOINT env var
kafka_api_key = var.kafka_api_key # optionally use KAFKA_API_KEY env var
kafka_api_secret = var.kafka_api_secret # optionally use KAFKA_API_SECRET env var
}
# Create the resources
so rest_endpoint
is an optional argument now.
Let me know if it helps.
Context
Problem
Terraform Plan does not show any issues when accidentally omitting the
rest_endpoint
parameter, this error is only revealed at apply time where the following error is thrown:This led to a situation where existing ACLs were destroying but failed to be recreated, resulting in small period of downtime for existing accounts.
Should the Provider warn about this missing field before allowing the user to run
terraform apply
?