-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug:] azurerm_cdn_frontdoor_rule
- allow the cdn_frontdoor_origin_group_id
field to be optional in the route_configuration_override_action
, expose Disabled
as a possible value of cache_behavior
#18906
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @WodansSon, unfortunately there's a test failure
------- Stdout: -------
=== RUN TestAccCdnFrontDoorRule_basicRegression18889
=== PAUSE TestAccCdnFrontDoorRule_basicRegression18889
=== CONT TestAccCdnFrontDoorRule_basicRegression18889
testcase.go:110: Step 1/2 error: Error running apply: exit status 1
Error: expanding 'actions': the 'route_configuration_override_action' block is not valid, 'forwarding_protocol' can not be defined if the 'cdn_frontdoor_origin_group_id' is not set, got "HttpsOnly"
with azurerm_cdn_frontdoor_rule.test,
on terraform_plugin_test.tf line 49, in resource "azurerm_cdn_frontdoor_rule" "test":
49: resource "azurerm_cdn_frontdoor_rule" "test" {
--- FAIL: TestAccCdnFrontDoorRule_basicRegression18889 (168.80s)
FAIL
@stephybun, sorry about that I thought I marked this as |
azurerm_cdn_frontdoor_rule
- allow the route_configuration_override_action
field to be optionalazurerm_cdn_frontdoor_rule
- allow the route_configuration_override_action
field to be optional
My test finally ran after over 5 hours of waiting, it appears I need to add some extra validation around the input values during create... 😭 |
azurerm_cdn_frontdoor_rule
- allow the route_configuration_override_action
field to be optionalazurerm_cdn_frontdoor_rule
- allow the route_configuration_override_action
field to be optional
"forwarding_protocol": { | ||
Type: pluginsdk.TypeString, | ||
Optional: true, | ||
Default: string(cdn.ForwardingProtocolMatchRequest), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this now need to be Computed
since this will come back as MatchRequest
from the service?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This cannot be Computed
because that would cause a perpetual diff since you would not actually be able to clear the value, which is required to make this to work correctly. I do still set the default
value, but I had to move it to the expand function:
// set the default value for forwarding protocol to avoid a breaking change...
if protocol == "" {
protocol = string(cdn.ForwardingProtocolMatchRequest)
}
I do realize that the existing resources will now get a diff if they do not update there config to actually define the forwarding_protocol
field, but I am not sure how to work around that. If you have any suggestions on how to accomplish that I am all ears. 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Due to another issue (mentioned in the comment thread of the original issue) I had to make every field for this action
optional and fix it in the expand
/flatten
functions of the resource. This is all related to Portal magic, I have added the following to the documentation NOTE to the route_configuration_override_action
block. I know this is not ideal, but I feel this is the best that we can do given the cards we have been delt.
NOTE: | While cache_duration , cache_behavior and query_string_caching_behavior do have default values, if you do not define these properties in your configuration file you will receive a diff during plan. |
---|
@stephybun, I am sorry I had to cancel your build on the TC server because I resolved the documentation conflict with main. However, after KT merged the documentation PR and before I resolved the documentation conflict I did kick off a new TC build of this PR and I will attach the results to this comment thread once it completes. Feel free to kick off another one if you'd like for due diligence. 🙂 |
originGroupId = *group.ID | ||
// NOTE: Need to normalize this ID here because if you modified this in portal the resourceGroup comes back as resourcegroup. | ||
// ignore the error here since it was set on the resource in Azure and we know it is valid. | ||
if originGroup, err := parse.FrontDoorOriginGroupIDInsensitively(*override.OriginGroup.ID); err == nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in the Expand function we should be parsing these case-sensitively:
if originGroup, err := parse.FrontDoorOriginGroupIDInsensitively(*override.OriginGroup.ID); err == nil { | |
if originGroup, err := parse.FrontDoorOriginGroupID(*override.OriginGroup.ID); err == nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added this code specifically because if I created the rule in the portal and attempted to import it it would fail because of the casing of the resource group segment(e.g. resourcegroup
vs. resourceGroup
). This code is in the FlattenCdnFrontDoorRouteConfigurationOverrideAction where it gets the info from the API and not the Configuration file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
apologies that's my bad for missing this was in the Flatten and not the Expand - we should raise this error if this fails to pass, but this is otherwise fine 👍
azurerm_cdn_frontdoor_rule
- allow the route_configuration_override_action
field to be optionalazurerm_cdn_frontdoor_rule
- allow the cdn_frontdoor_origin_group_id
field to be optional in the route_configuration_override_action
, expose Disabled
as a possible value of cache_behavior
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a few comments inline, but this otherwise LGTM 👍
// set the default value for forwarding protocol to avoid a breaking change... | ||
if protocol == "" { | ||
protocol = string(cdn.ForwardingProtocolMatchRequest) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this'll want to be changed in v4.0, so could we feature-flag this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally believe that we should keep the default values in v4.0 as well since the service will return a 400 bad request error if the fields are not in the create/update call. I can feature-flag them if you would like, but I think that would lead to a bad user experience in v4.0 if we remove them.
return nil, fmt.Errorf("the 'route_configuration_override_action' block is not valid, 'query_string_parameters' must not be set if the'query_string_caching_behavior' is set to 'UseQueryStrings' or 'IgnoreQueryStrings'") | ||
// since 'cache_duration', 'query_string_caching_behavior' and 'cache_behavior' are optional create a default values | ||
// for those values if not set. | ||
cacheDuration := "1.12:00:00" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there some context for this default value, presumably this is coming from the API's default value/the portal or something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is, Front Door will default the cache to somewhere between 1 to 3 days, I have no way of knowing what Front Door decided and since I had to offer a default value to match the portal experience and this field has to be optional now I picked a value in the middle of what the Front Door documentation says the cache range can be... it seemed to me to be the lesser of the two evils and also allows for parity in functionality between Terraform and the Portal.
originGroupId = *group.ID | ||
// NOTE: Need to normalize this ID here because if you modified this in portal the resourceGroup comes back as resourcegroup. | ||
// ignore the error here since it was set on the resource in Azure and we know it is valid. | ||
if originGroup, err := parse.FrontDoorOriginGroupIDInsensitively(*override.OriginGroup.ID); err == nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
apologies that's my bad for missing this was in the Flatten and not the Expand - we should raise this error if this fails to pass, but this is otherwise fine 👍
@@ -197,7 +197,9 @@ An `url_redirect_action` block supports the following: | |||
|
|||
A `route_configuration_override_action` block supports the following: | |||
|
|||
* `cache_duration` - (Required) When Cache behavior is set to `Override` or `SetIfMissing`, this field specifies the cache duration to use. The maximum duration is 366 days specified in the `d.HH:MM:SS` format(e.g. `365.23:59:59`). If the desired maximum cache duration is less than 1 day then the maximum cache duration should be specified in the `HH:MM:SS` format(e.g. `23:59:59`). | |||
->**NOTE:** While `cache_duration`, `cache_behavior` and `query_string_caching_behavior` do have default values, if you do not define these properties in your configuration file you will receive a diff during plan. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is the default behaviour for Terraform properties, perhaps what we should be saying is something along the lines of: "you can use Terraform's ignore_changes
functionality to ignore these default values`?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🍄
This functionality has been released in v3.29.0 of the Terraform Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you! |
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
Optional
cdn_frontdoor_origin_group_id
:cdn_frontdoor_origin_group_id
you cannot defineforwarding_protocol
as this would result in an error from the API.(fixes #18889)
Disable Cache Without the Origin Group ID:
Disable Cache With the Origin Group ID:
(fixes #19008)