nsxt_policy_group member_type policy evolve

Describe the bug

Today, I have Version 4.1.1.0.0.22224312 NSXT which one can filter nsxt_policy_group member_type SegmentPort and Segment. But I tried from terraform : criteria { condition { member_type = "SegmentPort" <==== key = "Tag" operator = "EQUALS" value = "vsphere_port|${var.ports[0]}" } condition { member_type = "Segment" <==== key = "Tag" operator = "EQUALS" value = "*{var.nsx_tag}|${var.net}" } } I can do this

Reproduction steps

1. write tf file with nsxt_policy_group defined earlier
2. launch terraform
3. observe Error : Error: Nested conditions must all use the same member_type, but found 'Segment' with 'SegmentPort' │ │ with nsxt_policy_group.networkTag["monitoring_support"], │ on 3-nsx.tf line 366, in resource "nsxt_policy_group" "networkTag": │ 366: resource "nsxt_policy_group" "networkTag" { ...

Expected behavior

Maybe let NSX API reply for you despite of avoiding unsupported configuration

Additional context

No response

Thanks @llebotlan, indeed we should remove this validation as NSX allows combinations now

Adding this issue to the 3.7.0 milestone after discussing it with @annakhm

Moving this issue to 3.8.0 due to release timeline constraints.

Moving this issue to 3.8.0 due to release timeline constraints.

Hi @salv-orlando , also following this issue as well, what's the 3.8.0 release timeline ?

For the context, need this for the following:

` resource "nsxt_policy_group" "test-app-group2" {

display_name = "test-app-group2"

criteria {
    condition {
        key         = "Name"
        member_type = "KubernetesCluster"
        operator    = "EQUALS"
        value       = "domain-c9_xxxxxxx-antrea"
    }
    condition {
        key         = "Name"
        member_type = "KubernetesNamespace"
        operator    = "EQUALS"
        value       = "test-app"
    }
    condition {
        key         = "Name"
        member_type = "KubernetesService"
        operator    = "EQUALS"
        value       = "test-app-service"
    }
}

} `

Moving this issue to 3.8.0 due to release timeline constraints.

Hi @salv-orlando , also following this issue as well, what's the 3.8.0 release timeline ?

@gorkemozlu release timeline is available here

Hi team @salv-orlando @ksamoray , it looks like tomorrow is the release day for 3.8.0, just checking in for this issue, we still need this :)

@gorkemozlu Unfortunately we need to move this to the v3.9.0 as we're close to the 3.8.0 release (which will be moved by a week in any case). This is a relatively complex use case to address with NSX groups.

We will keep it however in our priority list for v3.9.0. Btw, the issue is assigned to @annakhm!