nsxt_policy_group conjection default to OR

[jvboyle]

Is your feature request related to a problem? Please describe.

when setting dynamic criteria with for_each loops , the need to set conjunction is required for multi server sets , the default behavior of OR , limits the use of the group because it infers only 1 object in the list would added. if this is set to AND , you can built a list of objects and the function of the "grouping " would be as intended

Describe the solution you'd like

criteria {
condition {
key = "Name"
member_type = "VirtualMachine"
operator = "EQUALS"
value = "server1"
}
}
conjunction {
operator = "OR"
}

criteria {
condition {
key = "Name"
member_type = "VirtualMachine"
operator = "EQUALS"
value = "server2"
}
}

Describe alternatives you've considered

No response

Additional context

No response

[annakhm]

Hi @jvboyle, sorry for delay in response.
Could you please provide an example of the for_each loop that is not possible today, thanks!

[llebotlan]

Hello, thank you for the issue. I am wondering how to solve it. In my case, I have var.list = [ "porttag1", "porttag2" ], which are tag of interface on a segment. I want to create resources nsxt_policy_group "myPort" with both ports:
resource "nsxt_policy_group" "networkTag" {
...
dynamic "criteria" {
for_each = var.list
content {
condition {
member_type = "SegmentPort"
key = "Tag"
operator = "EQUALS"
value = "${criteria.value}"
}
conjunction { # <== how to iterate outside the criteria block
operator = "OR"
}
}
}
}
}

[llebotlan]

I want:
resource "nsxt_policy_group" "networkTag" {
...
criteria {
condition {
value = "porttag1"
...
}
}
conjunction {
operator = "OR"
}
// then the second item

criteria {
condition {
value = "porttag2"
...
}
}

[llebotlan]

I do not find another solution than with var.ports the list of port: :-(

resource "nsxt_policy_group" "networkTag" {
...
criteria {
condition {
member_type = "SegmentPort"
key = "Tag"
operator = "EQUALS"
value = "vsphere_port|${var.ports[0]}"
}
}

dynamic "conjunction" {
for_each = length(var.ports) >1 ? [1] : []
content {
operator = "OR"
}
}
dynamic "criteria" {
for_each = length(each.value.ports) >1 ? [1] : []
content {
condition {
member_type = "SegmentPort"
key = "Tag"
operator = "EQUALS"
value = "vsphere_port|${var.ports[1]}"
}
}
}

dynamic "conjunction" {
for_each = length(var.ports) >2 ? [1] : []
content {
operator = "OR"
}
}
dynamic "criteria" {
for_each = length(var.ports) >2 ? [1] : []
content {
condition {
member_type = "SegmentPort"
key = "Tag"
operator = "EQUALS"
value = "vsphere_port|${var.ports[2]}"
}
}
...
}

[martinrohrbach]

I'm not sure that what @llebotlan is asking is the same as what @jvboyle initially created the issue for. However, I do have a suggestion for the latest problem.

Intuitively you might think that the resource definition must look like this:

criteria - conjunction - criteria - conjunction - criteria ...

The way the resource is defined though, the provider is totally fine with:

criteria - criteria - criteria - conjunction - conjunction

As long as the number of conjuctions is one less than the number of criteria. As such you can define a dynamic resource like this:

locals {
  tag_list = ["test1", "test2", "test3"]
}

resource "nsxt_policy_group" "trf-group-by-tags" {
  display_name = "trf-group-by-tags"

  dynamic "criteria" {
    for_each = local.tag_list

    content {
      condition {
        member_type = "SegmentPort"
        key         = "Tag"
        operator    = "EQUALS"
        value       = criteria.value
      }
    }
  }

  dynamic "conjunction" {
    for_each = slice(local.tag_list, 0, length(local.tag_list) - 1)

    content {
      operator = "OR"
    }
  }
}

Obviously the conjunction can be changed to "AND" and you could also have a seperate array variable for the conjunction if required. Maybe that helps?

[annakhm]

For the ease of dynamic blocks, we can change the terraform side code to ignore the last conjunction, so that the number of conjunctions and conditions will be equal. Would that help @llebotlan @jvboyle?
Thank you @martinrohrbach for the example above.

[llebotlan]

Hello, i do not think so, because it is a complexe(not logical) workaround. But a warning and the previous exemple in the manual, would be better (from my point of view)