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

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

Open
Nacymus opened this issue Apr 18, 2024 · 3 comments · Fixed by #1197
Assignees
Labels
awaiting-response Awaiting Response bug Bug

Comments

@Nacymus
Copy link

Nacymus commented Apr 18, 2024

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

@Nacymus Nacymus added the bug Bug label Apr 18, 2024
@annakhm annakhm linked a pull request Apr 25, 2024 that will close this issue
@annakhm
Copy link
Collaborator

annakhm commented Apr 25, 2024

Thanks for reporting!

@Nacymus
Copy link
Author

Nacymus commented May 24, 2024

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
Copy link
Collaborator

annakhm commented May 24, 2024

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!

@annakhm annakhm reopened this May 24, 2024
@annakhm annakhm added the awaiting-response Awaiting Response label Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting-response Awaiting Response bug Bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants