Skip to content
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

Unnecessary VPC endpoint replacement when using clickhouse_private_endpoint_config (issue with deprecated attribute) #172

Closed
tstraley opened this issue Oct 16, 2024 · 3 comments

Comments

@tstraley
Copy link

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:

  1. 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).
  2. The data.clickhouse_private_endpoint_config source must include a depends_on clause waiting for the clickhouse_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).
  3. 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.

@whites11
Copy link
Contributor

@tstraley thanks a lot for your detailed report!

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.

Thanks again

@tstraley
Copy link
Author

I see you found a workaround

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?

@whites11
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants