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

Applies of nsxt_policy_predefined_security_policy are inconsistent and non-idempotent #631

Open
neil-wwt opened this issue Jun 7, 2021 · 3 comments
Labels

Comments

@neil-wwt
Copy link

neil-wwt commented Jun 7, 2021

Terraform CLI and Terraform Provider Version

Terraform v0.15.5
on windows_amd64
+ provider registry.terraform.io/vmware/nsxt v3.1.1

Affected Resource(s)

nsxt_policy_predefined_security_policy

Terraform Configuration Files

terraform {
  required_providers {
    nsxt = {
      source = "vmware/nsxt"
      version = "3.1.1"
    }
  }
}

provider "nsxt" {
# Your creds here
}

data "nsxt_policy_security_policy" "default_app_policy" {
  is_default = true
  category   = "Application"
}

resource "nsxt_policy_predefined_security_policy" "default_app_policy" {
  path = data.nsxt_policy_security_policy.default_app_policy.path
  default_rule {
    action = "DROP"
  }
}

Expected Behavior

  1. Run apply the first time. Change default rule to DROP (or whatever is specified) and do something (or don't) with other existing rules in that policy. (Not sure what the expected behavior is in regards to other rules)
  2. Run apply again and nothing else changes

Actual Behavior

  1. On the first apply, the default rule is modified. TF reports "1 to add"

  2. On the second apply, the other rules in the default policy are removed. TF reports "1 changed"

  3. On the second apply, the default rule is created. TF reports "1 to add"

Steps to Reproduce

  1. Have NSX-T default policy with at least one manually created rule. In this example, called Test
  2. terraform apply
    • On the first apply, the default rule is created. TF reports "1 to add"
Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # nsxt_policy_predefined_security_policy.default_app_policy will be created
  + resource "nsxt_policy_predefined_security_policy" "default_app_policy" {
      + description = (known after apply)
      + id          = (known after apply)
      + path        = "/infra/domains/default/security-policies/default-layer3-section"
      + revision    = (known after apply)

      + default_rule {
          + action          = "DROP"
          + description     = (known after apply)
          + logged          = false
          + nsx_id          = (known after apply)
          + path            = (known after apply)
          + revision        = (known after apply)
          + scope           = (known after apply)
          + sequence_number = (known after apply)
        }
    }

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

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

nsxt_policy_predefined_security_policy.default_app_policy: Creating...
nsxt_policy_predefined_security_policy.default_app_policy: Creation complete after 1s [id=default-layer3-section]
  1. Check NSX-T console. You will see the Test rule is still in place.

  2. terraform apply

    • After making no changes in code or console.
    • On the second apply, the other rules in the default policy are removed. TF reports "1 changed"
nsxt_policy_predefined_security_policy.default_app_policy: Refreshing state... [id=default-layer3-section]

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # nsxt_policy_predefined_security_policy.default_app_policy will be updated in-place
  ~ resource "nsxt_policy_predefined_security_policy" "default_app_policy" {
        id       = "default-layer3-section"
        # (2 unchanged attributes hidden)


      - rule {
          - action                = "ALLOW" -> null
          - destination_groups    = [] -> null
          - destinations_excluded = false -> null
          - direction             = "IN_OUT" -> null
          - disabled              = false -> null
          - display_name          = "Test" -> null
          - ip_version            = "IPV4_IPV6" -> null
          - logged                = false -> null
          - nsx_id                = "Test" -> null
          - profiles              = [] -> null
          - revision              = 0 -> null
          - rule_id               = 0 -> null
          - scope                 = [] -> null
          - sequence_number       = 499999 -> null
          - services              = [] -> null
          - source_groups         = [] -> null
          - sources_excluded      = false -> null
        }
        # (1 unchanged block hidden)
    }

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

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

nsxt_policy_predefined_security_policy.default_app_policy: Modifying... [id=default-layer3-section]
nsxt_policy_predefined_security_policy.default_app_policy: Modifications complete after 1s [id=default-layer3-section]

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.
  1. Check NSX-T console. You will see the Test rule has been removed.
@neil-wwt
Copy link
Author

neil-wwt commented Jun 7, 2021

I'm not sure what the expected behavior is in regards to other rules in the default policy. I can see an argument for both leaving alone and removing manually created rules. The issue here is that the behavior is inconsistent across back-to-back runs of terraform apply

I also realize that this resource (nsxt_policy_predefined_security_policy) is in beta but thought it would be important to call out this bug so it could be addressed

@annakhm annakhm added the bug label Jun 9, 2021
@github-actions
Copy link

github-actions bot commented Jun 5, 2022

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

@github-actions github-actions bot added the stale label Jun 5, 2022
@annakhm annakhm removed the stale label Jun 15, 2022
@github-actions
Copy link

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

@github-actions github-actions bot added the stale label Jun 11, 2023
@annakhm annakhm removed the stale label Jul 11, 2023
@annakhm annakhm reopened this Jul 11, 2023
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

2 participants