Terraform-provider-azurerm: azurerm_eventgrid_event_subscription support advanced filtering

[bfleming-ciena]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Looking for the advanced filtering option. Presently it has subject filtering for beginswith and endswith which is good, but my use-case was to use the advance filter to search the subject for a string that's contained in the subject "i.e. virtualMachines, storageAccounts".

New or Affected Resource(s)

• azurerm_eventgrid_event_subscription

Potential Terraform Configuration

subject_filter {
string_contains = "blah"
}

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.

References

• #0000

[BadgerCode]

Some examples can be found in the documentation
https://docs.microsoft.com/en-us/azure/event-grid/event-filtering#advanced-filtering

"filter": {
  "advancedFilters": [
    {
      "operatorType": "NumberGreaterThanOrEquals",
      "key": "Data.Key1",
      "value": 5
    },
    {
      "operatorType": "StringContains",
      "key": "Subject",
      "values": ["container1", "container2"]
    }
  ]
}

• There can be up to 5 rules.
• The value can be a string/number/bool or an array with up to 5 values.
• The operators available are
  
  
  
  • NumberGreaterThan, NumberGreaterThanOrEquals, NumberLessThan, NumberLessThanOrEquals, NumberIn, NumberNotIn
  
  
  • BoolEquals
  
  
  • StringContains, StringBeginsWith, StringEndsWith, StringIn, StringNotIn
  
  

[BadgerCode]

This should probably go in a new section as you can have both subject_filter and advanced_filter rules.
E.g.

subject_filter {
  subject_begins_with = "xyz"
}

advanced_filter {
  operator = "NumberGreaterThanOrEquals"
  key = "Data.Key1"
  value = 5
}

advanced_filter {
  operator = "StringContains"
  key = "Subject"
  values = [
    "xyzcontainer1",
    "xyzcontainer2"
  ]
}

[BadgerCode]

Is there anyone that could take a look at this?
These features are incredibly useful.

We've had to make do with ARM templates for the past 7 months.

[jrauschenbusch]

Hi @BadgerCode

your proposed syntax would be really nice and clean, but unfortunately TF schema and state handling would not be that nice.

example.tf

resource "azurerm_eventgrid_event_subscription" "example" {

  [...]

  advanced_filter {
    key = "subject"
    operator = "StringContains"
    values = [
      "virtualMachines",
      "storageAccounts"
    ]
  }

  advanced_filter {
    key = "Data.AnyNumber"
    operator = "NumberGreaterThanOrEquals"
    value = 42
  }

}

terraform.tfstate:

{
  "version": 4,
  "terraform_version": "0.12.21",
  "serial": 0,
  "lineage": "",
  "outputs": {},
  "resources": [
    {
      "mode": "managed",
      "type": "azurerm_eventgrid_event_subscription",
      "name": "example",
      "provider": "provider.azurerm",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "advanced_filter": [
              {
                "key": "subject",
                "operator_type": "StringContains",
                "value": null,
                "values": [
                  "virtualMachines",
                  "storageAccounts"
                ]
              },
              {
                "key": "Data.AnyNumber",
                "operator_type": "NumberGreaterThanOrEquals",
                "value": "42",
                "values": null
              }
            ],
            [...]
        }
      ]
    }
  ]
}

Advantages:

• Clean and easy usage
• One property name for a one purpose
• Limitation to max. 5 rules could be easily implemented in the resource schema using MinItems/MaxItems rules. This would also be checked within terraform plan stage.

Disadvantages:

• TF state would always consist of both properties per filter, value and values, but only one item is set the other is always null.
• ConflictsWith rule does currently not work for Set and Lists (https://github.com/hashicorp/terraform-plugin-sdk/issues/71). Hence it is not possible to validate during terraform plan that either value or values is used, but not both.
• OperatorType specifies if either value or values is required. This is imho also not possible using the current TF schema validation functionality.

Disadvantages to accept if no dedicated scope for each operator type should be implemented:

• Required type conversions:
  
  
  
  • Type of value can be float64 or boo
  
  
  • Type of values fields can be string or float64
  
  
  • ..., but TF is smart enough to allow primitive types in configuration files which are then converted to strings. One has to parse them internally back to the required type.
  
  

I've created an implementation providing two:advanced_filter_scalar and advanced_filter_array. But i'm still not really happy with this partition. Maybe some feedback would help me to find a decision.

[hashibot[bot]]

This has been released in version 2.13.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example:

provider "azurerm" {
    version = "~> 2.13.0"
}
# ... other configuration ...

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!