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

discovered_networks in avi_pool causes an update on each plan/apply #571

Open
giovannibaratta opened this issue Dec 4, 2023 · 6 comments
Assignees
Labels

Comments

@giovannibaratta
Copy link

Describe the bug

When creating a resource of type avi_pool, leaving the attribute discovered_networks in servers will produce a diff in subsequent plan/apply.

Reproduction steps

resource "avi_pool" "pool2" {
  name                = "additional-pool"
  cloud_ref           = var.cloud_id
  default_server_port = 8200
  health_monitor_refs = [avi_healthmonitor.hm.id]

  servers {
    ip {
      type = "V4"
      addr = "172.17.0.14"
    }
    hostname = "this-is-a-value"
  }

  ssl_profile_ref = avi_sslprofile.pool_profile.id
}

Result in this terraform diff

Terraform will perform the following actions:

  # module.vault_cluster.module.lb[0].avi_pool.pool2 will be updated in-place
  ~ resource "avi_pool" "pool2" {
        id                                    = "https://172.17.0.30/api/pool/pool-feafecc3-1b69-466f-91dd-c4d4c6d8c0a6"
        name                                  = "additional-pool"
        # (38 unchanged attributes hidden)

      ~ servers {
            # (7 unchanged attributes hidden)

          - discovered_networks {
              - network_ref = "https://172.17.0.30/api/network/dvportgroup-4033-cloud-746a7edc-7d79-49f4-bffb-c8cc2a05967b" -> null

              - subnet {
                  - mask = "16" -> null

                  - ip_addr {
                      - addr = "172.17.0.0" -> null
                      - type = "V4" -> null
                    }
                }
            }

            # (1 unchanged block hidden)
        }

        # (1 unchanged block hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Expected behavior

Terraform should not generate any difference during subsequent plan/apply

Additional context

From my understanding discovered_networks should be an internal-use attribute and it should not even be proposed as an editable attribute in terraform. In this case, leaving the attribute unset will produce the diff posted above.

@Rohan-sss1
Copy link
Collaborator

HI @giovannibaratta I tried to reproduce the issue using the provided terraform config but unable to reproduce it. Can you provide the alb provider and controller version which you are using?
Also add if you are performing any manual operations on pool from UI side

@giovannibaratta
Copy link
Author

giovannibaratta commented Dec 6, 2023

The terraform provider version is 22.1.5
The controller version is 30.1.1-9415

provider "avi" {
   ...
  avi_version    = "30.1.1"
}

All the AVI resources are provisioned using Terraform except for the Cloud configuration. The behavior is observed is subsequent runs (terraform plan/apply) without the need of open the UI.

@Rohan-sss1
Copy link
Collaborator

@giovannibaratta Thanks for raising this issue; I am able to reproduce the issue. In the release of 22.1.5, we fixed the issue to track the UI side changes. While applying the Terraform plan, earlier it was not there; that's why it is showing diff, and some internal fields are part of the resource schema; those fields should not come.
I will update here once I fix the issue.

Thanks

@Rohan-sss1 Rohan-sss1 self-assigned this Dec 6, 2023
@lopf
Copy link

lopf commented Apr 17, 2024

As this is really annoying, is there an ETA for the fix? Running provider 22.1.5 with controller 22.1.5 2p3 build 9093.

@lopf
Copy link

lopf commented Jul 30, 2024

We're still desperately waiting for this to be fixed. Can you @Rohan-sss1 provide an ETA?

@tthrone-atomic
Copy link

I would like to bump this @Rohan-sss1. We are still experiencing the same issue (provider 30.2.2 with controller 30.1.2).

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

No branches or pull requests

4 participants