Bug: azurerm_frontdoor fix for caching issue
#4618
Conversation
|
|
| "cache_use_dynamic_compression": { | ||
| Type: schema.TypeBool, | ||
| Optional: true, | ||
| Default: false, |
There was a problem hiding this comment.
I think this will end up causing people a diff?
There was a problem hiding this comment.
I don't think this will be an issue since it's data type is bool, it is always false by default... WDYT?
| "cache_query_parameter_strip_directive": { | ||
| Type: schema.TypeString, | ||
| Optional: true, | ||
| ValidateFunc: validation.StringInSlice([]string{ | ||
| string(frontdoor.StripAll), | ||
| string(frontdoor.StripNone), | ||
| }, false), | ||
| Default: string(frontdoor.StripNone), |
There was a problem hiding this comment.
This is a breaking change? we can't do this until 2.0
There was a problem hiding this comment.
No, this is not a breaking change because the value is never evaluated unless the cache_use_dynamic_compression is set to true. So this is basically a NoOp… WDYT?
There was a problem hiding this comment.
Looks like setting it to StripNone or StripAll won't change the 'caching' field but only the 'Query string caching behaviour'. Is there a way to change the 'caching' field?
azurerm/resource_arm_front_door.go
Outdated
| @@ -198,7 +199,7 @@ func resourceArmFrontDoor() *schema.Resource { | |||
| string(frontdoor.HTTPSOnly), | |||
| string(frontdoor.MatchRequest), | |||
| }, false), | |||
| Default: string(frontdoor.MatchRequest), | |||
| Default: string(frontdoor.HTTPSOnly), | |||
There was a problem hiding this comment.
This is a breaking change? we can't do this until 2.0
There was a problem hiding this comment.
Reverted default value change to avoide the breaking change, will open issue to update this in the 2.0 timeframe.
| // portal-front-door/ -> healthProbeSettings/healthProbeSettings-1571100669337 | ||
| // | ||
| // but in the HealthProbeSettings block the casing of the HealthProbeSettings is (notice the uppercase 'H'):: | ||
| // portal-front-door/ -> HealthProbeSettings/healthProbeSettings-1571100669337 |
There was a problem hiding this comment.
it'd be worth raising this as a bug in the API - since the ARM Specification states that the same Resource ID should be returned in the same casing for the same API call, wherever it's present.
It's probably also worth calling out specifically that whilst the ARM Specification "technically" says Resource ID's are case insensitive; in practice they're not since both downstream API's and downstream client's don't consume them in that fashion - which I think is a larger discussion we need to have with the ARM Team 🙃
|
This has been released in version 1.41.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 = "~> 1.41.0"
}
# ... other configuration ... |
|
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! |
ghost
locked and limited conversation to collaborators
Real fix for #4461