You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When following the example AWS private endpoint configuration as documented here, any changes to the clickhouse_service resource results in the terraform plan thinking it must replace the aws_vpc_endpoint.
As an example, if I simply change the max_replica_memory_gb parameter, I end up with the following plan:
# module.clickhouse.clickhouse_service.main will be updated in-place
~ resource "clickhouse_service" "main" {
id = "REDACTED"
- max_replica_memory_gb = 16
+ max_replica_memory_gb = 32
name = "my-clickhouse-service"
# (12 unchanged attributes hidden)
}
# module.clickhouse.data.clickhouse_private_endpoint_config.main will be read during apply
# (depends on a resource or a module with changes pending)
<= data "clickhouse_private_endpoint_config" "main" {
+ cloud_provider = "aws"
+ endpoint_service_id = (known after apply)
+ region = "us-east-1"
}
# module.clickhouse.aws_vpc_endpoint.clickhouse_privatelink must be replaced
-/+ resource "aws_vpc_endpoint" "clickhouse_privatelink" {
~ arn = "arn:aws:ec2:us-east-1:REDACTED:vpc-endpoint/vpce-026d8f344cc40b494" -> (known after apply)
~ cidr_blocks = [] -> (known after apply)
~ dns_entry = [
...
},
] -> (known after apply)
~ id = "vpce-026d8f344cc40b494" -> (known after apply)
~ ip_address_type = "ipv4" -> (known after apply)
~ network_interface_ids = [
...
] -> (known after apply)
~ owner_id = "REDACTED" -> (known after apply)
~ policy = jsonencode(
{
- Statement = [
- {
- Action = "*"
- Effect = "Allow"
- Principal = "*"
- Resource = "*"
},
]
}
) -> (known after apply)
+ prefix_list_id = (known after apply)
~ requester_managed = false -> (known after apply)
~ route_table_ids = [] -> (known after apply)
~ service_name = "com.amazonaws.vpce.us-east-1.vpce-svc-0abfc56oc7bf6o04b" # forces replacement -> (known after apply) # forces replacement
~ state = "available" -> (known after apply)
- tags = {} -> null
# (6 unchanged attributes hidden)
- dns_options {
- dns_record_ip_type = "ipv4" -> null
- private_dns_only_for_inbound_resolver_endpoint = false -> null
}
}
This bug is a culmination of several issues:
The private_endpoint_config attribute was deprecated from the clickhouse_service resource. It isn't clear why this is deprecated when the data provided from this attribute was sensible and useful coming from the created resource (and there is no alternative for getting the private_dns_hostname Private Endpoint Config DEPRECATED #72).
Terraform cannot determine the result of the endpoint_service_id from this data lookup during plan, when it depends up on a resource that is going to change during apply.
To get around this, I have reverted back to using clickhouse_service.main.private_endpoint_config.endpoint_service_id instead of the data source. This works as expected, and results in a fully resolvable plan that doesn't include replacing the VPC endpoint. The only issue is this is reported as deprecated so I am concerned that it will be removed in a future release. I would strongly prefer this deprecation be reverted, or similar attributes be provided from the clickhouse_service resource. There doesn't appear to be any good reason to need a separate data source to perform this lookup.
The text was updated successfully, but these errors were encountered:
I agree with you there is confusion around the private endpoint management.
There are ongoing technical changes in our managed offering, and this is causing some delays in the capability to properly manage private endpoints in the terraform provider.
We hope to be able to solve this issue once and for all in the near future, thanks for your patience.
In the meantime, I see you found a workaround, so I'll move on and close this ticket. Feel free to reopen it if you need any help.
Otherwise, please subscribe to #72 to get updates on this topic.
My workaround utilizes deprecated attributes. Can I get some kind of clarification on whether these are planned for removal (which would take away this work around) or acknowledgement that they shouldn't be removed until a suitable alternative is in place?
This is still up for internal debate. My personal 100% unofficial feeling is that we will get rid of the data provider and remove the deprecation from the private_endpoint_config attribute.
When following the example AWS private endpoint configuration as documented here, any changes to the
clickhouse_service
resource results in the terraform plan thinking it must replace theaws_vpc_endpoint
.As an example, if I simply change the
max_replica_memory_gb
parameter, I end up with the following plan:This bug is a culmination of several issues:
private_endpoint_config
attribute was deprecated from theclickhouse_service
resource. It isn't clear why this is deprecated when the data provided from this attribute was sensible and useful coming from the created resource (and there is no alternative for getting the private_dns_hostname Private Endpoint Config DEPRECATED #72).data.clickhouse_private_endpoint_config
source must include adepends_on
clause waiting for theclickhouse_service
to be created, because otherwise the API request can fail if no clickhouse services already exist in the region and org (clickhouse_private_endpoint_registration requires cluster to be deployed before #48).endpoint_service_id
from this data lookup during plan, when it depends up on a resource that is going to change during apply.To get around this, I have reverted back to using
clickhouse_service.main.private_endpoint_config.endpoint_service_id
instead of the data source. This works as expected, and results in a fully resolvable plan that doesn't include replacing the VPC endpoint. The only issue is this is reported as deprecated so I am concerned that it will be removed in a future release. I would strongly prefer this deprecation be reverted, or similar attributes be provided from theclickhouse_service
resource. There doesn't appear to be any good reason to need a separate data source to perform this lookup.The text was updated successfully, but these errors were encountered: