azurerm_nginx_deployment - support NGINX App Protect WAF

[arpith-f5]

Community Note

• Please vote on this PR by adding a 👍 reaction to the original PR to help the community and maintainers prioritize for review
• Please do not leave comments along the lines of "+1", "me too" or "any updates", they generate extra noise for PR followers and do not help prioritize for review

Description

NGINXaaS now supports NGINX App Protect WAF. In order to use WAF, customers need to explicitly enable it while creating/update their NGINXaaS deployment. This commit includes changes to support a new block nginx_app_protect in azurerm_nginx_deployment resource to enable/disable WAF while creation or updating an NGINXaaS deployment.

PR Checklist

• I have followed the guidelines in our Contributing Documentation.
• I have checked to ensure there aren't other open Pull Requests for the same update/change.
• I have checked if my changes close any open issues. If so please include appropriate closing keywords below.
• I have updated/added Documentation as required written in a helpful and kind way to assist users that may be unfamiliar with the resource / data source.
• I have used a meaningful PR title to help maintainers and other users understand this change and help prevent duplicate work.
  For example: “resource_name_here - description of change e.g. adding property new_property_name_here”

Changes to existing Resource / Data Source

• I have added an explanation of what my changes do and why I'd like you to include them (This may be covered by linking to an issue above, but may benefit from additional explanation).
• I have written new tests for my resource or datasource changes & updated any relevent documentation.
• I have successfully run tests with my changes locally. If not, please provide details on testing challenges that prevented you running the tests.
• (For changes that include a state migration only). I have manually tested the migration path between relevant versions of the provider.

Testing

• My submission includes Test coverage as described in the Contribution Guide and the tests pass. (if this is not possible for any reason, please include details of why you did or could not add test coverage)

Manually tested create and update of a NGINXaaS deployment with WAF enabled/disabled

Change Log

Below please provide what should go into the changelog (if anything) conforming to the Changelog Format documented here.

• azurerm_nginx_deployment - support NGINX App Protect WAF

This is a (please select all that apply):

• Bug Fix
• New Feature (ie adding a service, resource, or data source)
• Enhancement
• Breaking Change

Related Issue(s)

Note

If this PR changes meaningfully during the course of review please update the title and description as required.

[puneetsarna]

Looks like some vendor checks are failing?

[puneetsarna]

I like the newly flattened structure (less nested) to invoke this new feature as well 👍

[arpith-f5]

Hi @katbyte @stephybun, when you get time would you be able to take a look at this PR. Thanks in advance!

[katbyte]

Hi, we have a test failure needing fixing:

------- Stdout: -------
=== RUN   TestAccNginxDeploymentDataSource_nginxappprotect
=== PAUSE TestAccNginxDeploymentDataSource_nginxappprotect
=== CONT  TestAccNginxDeploymentDataSource_nginxappprotect
    testcase.go:173: Step 1/1 error: Error running apply: exit status 1
        
        Error: scaling is required for `sku` 'standardv2_Monthly', please provide `capacity` or `auto_scale_profiles`
        
          with azurerm_nginx_deployment.test,
          on terraform_plugin_test.tf line 75, in resource "azurerm_nginx_deployment" "test":
          75: resource "azurerm_nginx_deployment" "test" {
        
        scaling is required for `sku` 'standardv2_Monthly', please provide `capacity`
        or `auto_scale_profiles`
--- FAIL: TestAccNginxDeploymentDataSource_nginxappprotect (92.49s)
FAIL

[puneetsarna]

Hi @katbyte!! I see @arpith-f5 pushed a fix for the test. Can you please re-run the tests and see if the issue persists?

[katbyte]

Thanks for the pr @arpith-f5 - i've given it a quick review and made some schema suggestions. let me know what you think

[katbyte]

this is a bool? so we should

Suggested change

	Type: pluginsdk.TypeString,
	Required: true,
	ValidateFunc: validation.StringInSlice(
	[]string{
	"Enabled",
	"Disabled",
	}, false),
	Type: pluginsdk.TypeBool,
	Required: true,

and then in the provider code translate true/false to Enabled Disabled, unless there is going to be a 3rd state here?

[puneetsarna]

The state is an enum.

[katbyte]

unless there is going to be a 3rd setting there in the future? this is a bool just represented as an enum and should be as such in the schema

[arpith-f5]

we initially designed the activation_state to be a bool in the schema but later changed to enum after recommendation from microsoft ARM team. Here is their reasoning

ARM recommends enums over booleans for future proof APIs. Standard guidance is: replace boolean/switch properties with a more meaningful enum whenever possible.

A boolean will forever have two valid values (true or false). A string enum type is always preferred. Also, properties should always provide better values just than True and False. For example two switches "isTypeA" and "isTypeB" should be replaced with one enum "type": [A, B, DefaultType]. Enums are always a more flexible and future proof option because they allow additional values to be added in the future in a non-breaking way, e.g. [Enabled, Disabled, Suspended, Deallocated].

Note: do NOT define a 'boolean enum' with two values 'True and False'. This might be easier to 'extend' in terms of types, but semantically its confusing, and no better than a boolean.

[katbyte]

As per our guidelines enums that are actually just booleans with different names should be booleans in schema with the correct name to telegraph what the boolean does https://github.com/hashicorp/terraform-provider-azurerm/blob/main/contributing/topics/reference-naming.md

[arpith-f5]

@katbyte updated the PR to use a bool instead of the enum

[katbyte]

Thanks for the pr @arpith-f5 - i've given it a quick review and made some schema suggestions. let me know what you think

[arpith-f5]

@katbyte would appreciate another look at this PR when convenient. Thanks in advance!