-
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
New Data Source/Resource: azurerm_cdn_frontdoor_origin_group
/ New Resource: azurerm_cdn_frontdoor_origin
#17089
Conversation
Porting across from #16671 Co-authored-by: Jeffrey Cline <[email protected]>
Splitting out from #16671 Co-authored-by: Jeffrey Cline <[email protected]>
Splitting this out from #16671 Co-authored-by: Jeffrey Cline <[email protected]>
"request_type": { | ||
Type: pluginsdk.TypeString, | ||
Required: true, | ||
ValidateFunc: validation.StringInSlice([]string{ | ||
string(cdn.HealthProbeRequestTypeGET), | ||
string(cdn.HealthProbeRequestTypeHEAD), | ||
}, false), | ||
}, |
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.
Should this be an optional field with the default as HEAD like 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.
Tbh I'd argue this, Protocol and Path want to be Required since these values are always going to be specific to the application/host being targeted, so we may as well make the three required so users are aware which healthcheck's configured to alleviate any confusion?
"certificate_name_check_enabled": { | ||
Type: pluginsdk.TypeBool, | ||
Optional: true, | ||
// TODO: should this default to `true`? | ||
}, |
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 believe from a security perspective that is the correct behavior, but iirc I made this false
because on the legacy Frontdoor resource the end users were complaining about having to set the value to false
as most of them ended up setting it to false
anyways, so I made false
the default in the new version as well. Totally up to you, I am fine either way, but if you do make the default true
we may get more issues about it. Another option here would be if we just make it a required
field and then the end users will have to make an explicit declaration of what it should be, so they will be fully aware of the security state of the origin group without assuming what the default value is? I think that is what I ended up doing in the legacy resource as well.
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 would also opt to make it a required field. The docs should also contain a note that this needs to be set to true when using private link
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.
Yeah making this required
would be fine - I'm surprised that this isn't defaulted to true
in the API tbh (since it's a security setting) - but 👍
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 have adjusted the schema and made this a required field
// TODO: approve the connection by looking up and updating the private link | ||
// data.CheckWithClient(func(ctx context.Context, clients *clients.Client, state *terraform.InstanceState) error { | ||
// clients.Network.PrivateLinkServiceClient.UpdatePrivateEndpointConnection() | ||
// }), |
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 am not sure, but it does make sense that it would be possible to do that. I had planned on investigating that after the release and just manually tested it in the interim as this resources was a large chunk of work to sort out, as you know. 🙂
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.
If approving could be automated by TF that would be awesome. But agree that it's probably not a P1 for release
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 guess there's potentially a resource here along the lines of azurerm_private_link_approval
or something? Whilst this isn't a blocker if we can manually test it - we do need this as a part of the test to ensure we're capturing this correctly, given deletion works slightly differently when there's a private link involved (as we've seen from other resources)
|
||
## Attributes Reference | ||
|
||
In addition to the Arguments listed above - the following Attributes are exported: |
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 it possible to export the private endpoint connection resource id, when using Private Link? that would make approval much easier instead of trying to pull out the connection afterwards.
@tombuildsstuff any updates on these? now that the first parts of AFDx have shipped, it would be great to get the missing pieces in, too |
@sebader due to other commitments I've had to hand this back to @WodansSon, but we'll give this a review when changes are pushed 👍 |
@sebader @tombuildsstuff I didn't realize when this was handed back to me that it also included this PR which was still in progress. I will pick this back up and try to get the rest of the resources shipped ASAP. |
I am going to skip the private link stuff for now since the resources have been delayed for quite some time now. Once all of the resources are released I will revisit the private link issues, but for now I believe leaving it a manual step is acceptable. |
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 @WodansSon but this otherwise LGTM, thanks for fixing this up - I can't approve it since I opened the PR though 🙃
|
||
* `location` - (Required) Specifies the location where the Private Link resource should exist. | ||
|
||
~> **Note:** For performance reasons this value should match the location of the `private_link_target_id` resource. |
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.
might be worth spelling this out since cross-region transfers have a cost-component too?
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.
|
||
The following arguments are supported: |
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.
The following arguments are supported: |
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.
"request_type": { | ||
Type: pluginsdk.TypeString, | ||
Required: true, | ||
ValidateFunc: validation.StringInSlice([]string{ | ||
string(cdn.HealthProbeRequestTypeGET), | ||
string(cdn.HealthProbeRequestTypeHEAD), | ||
}, false), | ||
}, |
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.
Tbh I'd argue this, Protocol and Path want to be Required since these values are always going to be specific to the application/host being targeted, so we may as well make the three required so users are aware which healthcheck's configured to alleviate any confusion?
cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.example.id | ||
session_affinity_enabled = true | ||
|
||
restore_traffic_time_to_healed_or_new_endpoint_in_minutes = 10 |
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 isn't documented below fwiw
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.
"certificate_name_check_enabled": { | ||
Type: pluginsdk.TypeBool, | ||
Required: true, | ||
// TODO: should this default to `true`? |
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 believe we chatted about this elsewhere and some folks wanted a default to false
, however we're defaulting this to Required
so folks can intentionally opt-out of this security feature if they're not concerned with SNI checks - so I don't think this is required? @WodansSon
// TODO: should this default to `true`? |
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.
"health_probes_enabled": { | ||
Type: pluginsdk.TypeBool, | ||
Optional: true, | ||
Default: false, |
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.
should this be defaulted to true?
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.
I do not believe the path should be required, because depending on what I would also tend to think that request_type should be optional with a default of HEAD as that matches the behavior in portal and the product documentation. |
…r-azurerm into f/cdn-frontdoor-origin-and-groups
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.
Aside from one comment this LGTM 🎩
@@ -1,20 +1,20 @@ | |||
## 3.14.0 (Unreleased) |
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.
you will have to roll back the merge main
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.
This functionality has been released in v3.15.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. |
This PR adds a new Data Source and Resource for
azurerm_cdn_frontdoor_origin_group
and a new Resource forazurerm_cdn_frontdoor_origin
- split out from #16671.I've left a couple of TODO's in here related to CDN FrontDoor Origin for @WodansSon, namely:
certificate_name_check_enabled
field be defaulted totrue
as this is a security related setting? (That's validating the hostname matches on the SSL certificate from the origin)