Skip to content
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

Merged
merged 16 commits into from
Jul 22, 2022

Conversation

tombuildsstuff
Copy link
Contributor

This PR adds a new Data Source and Resource for azurerm_cdn_frontdoor_origin_group and a new Resource for azurerm_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:

  1. Should the certificate_name_check_enabled field be defaulted to true as this is a security related setting? (That's validating the hostname matches on the SSL certificate from the origin)
  2. The Acceptance Tests need a custom Check function to approve the Private Link (which should be doable via retrieving the associated private link, from the info we have, and updating it?)

tombuildsstuff and others added 5 commits June 3, 2022 10:37
Porting across from #16671

Co-authored-by: Jeffrey Cline <20408400+WodansSon@users.noreply.github.com>
Splitting out from #16671

Co-authored-by: Jeffrey Cline <20408400+WodansSon@users.noreply.github.com>
Splitting this out from #16671

Co-authored-by: Jeffrey Cline <20408400+WodansSon@users.noreply.github.com>
Comment on lines 100 to 107
"request_type": {
Type: pluginsdk.TypeString,
Required: true,
ValidateFunc: validation.StringInSlice([]string{
string(cdn.HealthProbeRequestTypeGET),
string(cdn.HealthProbeRequestTypeHEAD),
}, false),
},
Copy link
Collaborator

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?

Copy link
Contributor Author

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?

Comment on lines 66 to 70
"certificate_name_check_enabled": {
Type: pluginsdk.TypeBool,
Optional: true,
// TODO: should this default to `true`?
},
Copy link
Collaborator

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.

Copy link
Contributor

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

Copy link
Contributor Author

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 👍

Copy link
Collaborator

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

Comment on lines +96 to +99
// 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()
// }),
Copy link
Collaborator

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. 🙂

Copy link
Contributor

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

Copy link
Contributor Author

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:
Copy link
Contributor

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 tombuildsstuff modified the milestones: v3.10.0, v3.11.0 Jun 10, 2022
@sebader
Copy link
Contributor

sebader commented Jun 20, 2022

@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

@jackofallops jackofallops modified the milestones: v3.11.0, v3.12.0 Jun 23, 2022
@tombuildsstuff
Copy link
Contributor Author

@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 👍

@tombuildsstuff tombuildsstuff modified the milestones: v3.12.0, v3.13.0 Jul 1, 2022
@manicminer manicminer modified the milestones: v3.13.0, v3.14.0 Jul 8, 2022
@WodansSon
Copy link
Collaborator

@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.

@WodansSon WodansSon added this to the v3.15.0 milestone Jul 13, 2022
@WodansSon
Copy link
Collaborator

WodansSon commented Jul 13, 2022

@tombuildsstuff

2. The Acceptance Tests need a custom Check function to approve the Private Link (which should be doable via retrieving the associated private link, from the info we have, and updating it?)

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.

@WodansSon WodansSon marked this pull request as ready for review July 13, 2022 21:54
@WodansSon
Copy link
Collaborator

image

Copy link
Contributor Author

@tombuildsstuff tombuildsstuff left a 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.
Copy link
Contributor Author

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?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

Comment on lines +26 to +27

The following arguments are supported:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The following arguments are supported:

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

Comment on lines 100 to 107
"request_type": {
Type: pluginsdk.TypeString,
Required: true,
ValidateFunc: validation.StringInSlice([]string{
string(cdn.HealthProbeRequestTypeGET),
string(cdn.HealthProbeRequestTypeHEAD),
}, false),
},
Copy link
Contributor Author

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
Copy link
Contributor Author

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

Copy link
Collaborator

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`?
Copy link
Contributor Author

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

Suggested change
// TODO: should this default to `true`?

Copy link
Collaborator

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,
Copy link
Contributor Author

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?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@WodansSon
Copy link
Collaborator

WodansSon commented Jul 22, 2022

@tombuildsstuff:

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?

I do not believe the path should be required, because depending on what request_type you use the path may not be needed since front door gets the URL from the backend. path is really only helpful in the GET scenario and most people do not use the GET request_type because every time the front door health check issues a GET call to ping the edge servers that edge server cost increases because it has to return a message-body in the response to the GET call. That said I do agree that the interval_in_seconds should be required as well, since that can affect the load on the edge servers, forcing the end users to pick this number I think is totally valid.

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.

@katbyte katbyte removed this from the v3.15.0 milestone Jul 22, 2022
@WodansSon WodansSon added this to the v3.16.0 milestone Jul 22, 2022
Copy link
Collaborator

@katbyte katbyte left a 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)
Copy link
Collaborator

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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@WodansSon
Copy link
Collaborator

image

@WodansSon WodansSon merged commit 3a01a8f into main Jul 22, 2022
@WodansSon WodansSon deleted the f/cdn-frontdoor-origin-and-groups branch July 22, 2022 03:03
WodansSon added a commit that referenced this pull request Jul 22, 2022
@WodansSon WodansSon modified the milestones: v3.16.0, v3.15.0 Jul 22, 2022
@github-actions
Copy link

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!

@github-actions
Copy link

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.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 25, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants