SNI certificates fail to be configured on the remote resource for nsxt_policy_lb_virtual_server

[Nacymus]

Describe the bug

I am using nsxt_policy_lb_virtual_server with the ssl_client sni_paths attribute. The SSL Client configuration of the Virtual server is as follows:

client_ssl {
    client_auth              = "REQUIRED"
    default_certificate_path = "path_to_default_certificate"
    ca_paths                 = ["path_to_ca_certificate"]
    certificate_chain_depth  = 3
    ssl_profile_path         = "path_to_cleint_ssl_profile"
    sni_paths = ["path_to_some_other_certificate"]
  }

When planning for the 1st time, I see changes on the sni_paths of my Virtual Server:

~ resource "nsxt_policy_lb_virtual_server" "virtual_server" {
        id                         = "e649dce3-5750-4a39-93e7-03e45880db63"
        # (17 unchanged attributes hidden)

      ~ client_ssl {
          ~ sni_paths                = [
              + "path_to_some_other_certificate",
            ]
            # (6 unchanged attributes hidden)
        }

        # (5 unchanged blocks hidden)
    }

On apply, I see that one resource has been updated as stated in the plan:

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

But this change does not appear on the remote Virtual Server, And the applied changes are not replicated on the state either, so on the next plan, terraform evaluated exactly the same changes as on the 1st plan.

The plugin logs show the following warning :

2024-04-18T10:20:24.996+0200 [WARN]  Provider "provider[\"registry.terraform.io/vmware/nsxt\"].az1" produced an unexpected new value for module.nsx_infra_az1.module.nsxt_loadbalancer_service["loadbalancer0"].nsxt_policy_lb_virtual_server.virtual_server["vip0"], but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .revision: was cty.NumberIntVal(0), but now cty.NumberIntVal(1)
      - .client_ssl[0].sni_paths: element 0 has vanished

Reproduction steps

1. Create a simple virtual server with the NSX-T provider
2. Configure a client_ssl profile with SNI certificates ...

Expected behavior

Applied changes on the SNI part of Client SSL config in Virtual server should be applied on the remote NSX-T resource

Additional context

No response

[annakhm]

Thanks for reporting!

[Nacymus]

Hello @annakhm ,

The fix that closed the issue resloved one part of the problem : reading SNI conf of the distant virtual server. Still, whan configuring SNI in Tf configurations, we see a permanent diff and the distant virtual server is not once updated.

[annakhm]

Hi @Nacymus, in my local testing I don't observe this problem - snis are updated successfully. Could you please provide your apply logs with TF_LOG="debug" and TF_LOG_PROVIDER_NSX_HTTP="debug"? That would help a lot with troubleshooting. Thank you!