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

Fix issues with frontdoor custom https configuration #7498

Merged
merged 19 commits into from
Jul 22, 2020
Merged

Fix issues with frontdoor custom https configuration #7498

merged 19 commits into from
Jul 22, 2020

Conversation

luigibk
Copy link
Contributor

@luigibk luigibk commented Jun 25, 2020

This PR aims to introduce the following changes:

A fix for the below issue which prevents custom https configurations in frontdoor from being updated properly

Separating the custom https configuration resource from the main frontdoor resource. This should allow for parallel update of these resources as currently they are processed serially and that always leads to a timeout given enough frontend endpoints or endless waiting given how long each custom https configuration update can take (e.g. certificate update).

(fixes #6057 )

@ghost ghost added the size/XL label Jun 25, 2020
@katbyte katbyte requested a review from WodansSon June 25, 2020 16:21
@luigibk
Copy link
Contributor Author

luigibk commented Jun 26, 2020

Hi @WodansSon
I currently have an issue at apply stage as after the custom https configurations get created (successfully) I get an error:

When applying changes to
azurerm_frontdoor_custom_https_configuration.example_custom_https_0, provider
"registry.terraform.io/-/azurerm" produced an unexpected new value for was
present, but now absent.
This is a bug in the provider, which should be reported in the provider's own
issue tracker.
Error: Provider produced inconsistent result after apply

and my tf state file is missing all the custom https config even if they have been created correctly.

@timja
Copy link
Contributor

timja commented Jul 1, 2020

Missing website documentation for new resource and any required updates to the existing documentation

luigibk and others added 2 commits July 1, 2020 10:34
Co-authored-by: Tim Jacomb <tim.jacomb@hmcts.net>
… code to resource_arm_frontdoor_custom_https_configuration_resource file.
@ghost ghost added the documentation label Jul 2, 2020
@luigibk luigibk marked this pull request as ready for review July 3, 2020 08:49
@luigibk
Copy link
Contributor Author

luigibk commented Jul 3, 2020

Hi @WodansSon

I have fixed the issue I asked about some time ago + a few others, did some clean up and have added docs. It would be great if you could have a look.

It's all working as far as I can see apart from one use case:

  • when I delete an endpoint + its custom https configuration, the 2 operations proceed in parallel and the custom https configuration disable returns an error as the endpoint has been (or is being) deleted. Not sure why that is so as a custom_https_configuration depends on its endpoint so my understanding is that the 2 operations should not run in parallel in the first place. Any ideas?

@luigibk
Copy link
Contributor Author

luigibk commented Jul 8, 2020

@WodansSon I think there might be a misunderstanding.
I added a comment in the related issue:
#6057 (comment)

@WodansSon
Copy link
Collaborator

@luigibk you need to format the HCL in your test code to get rid of the lint error. I tried fixing it for you but I was denied permission to push to your fork.

Copy link
Collaborator

@WodansSon WodansSon left a comment

Choose a reason for hiding this comment

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

@luigibk, I've left code suggestions to fix the lint errors.

Copy link
Collaborator

@WodansSon WodansSon left a comment

Choose a reason for hiding this comment

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

@luigibk, thanks for the PR, this is looking good... left a few comments, but overall it looks pretty good, this is really close to being able to be merged! 🚀

},

Schema: map[string]*schema.Schema{
"front_door_name": {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we change this to front_door_id instead of front_door_name? If you want to keep the front_door_name attribute can also you expose the front_door_id as a new attribute?

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 think the best solution is to actually add a frontend_endpoint_id and remove both front_door_name and frontend_endpoint_name as they can be derived from the id. That way it should be easier to manage from a user perspective and the implementation should not be more complex after removing those 2 fields. How does such a solution sound to you?

Copy link
Collaborator

Choose a reason for hiding this comment

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

That's a good idea, but because of the way Terraform works the core would not be able to build a proper dependency graph during the plan phase, if I am not mistaken, which is why we generally use the parent resources id attribute. You can give it a try and see if it builds a correct provisioning graph, but my gut is telling me it won't be able to connect the two together.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In this case the parent resource for the custom https configuration is the frontend endpoint. I've started work on this and it looks good so far. Hopefully won't be long before I commit it.

azurerm/internal/services/frontdoor/frontdoor_resource.go Outdated Show resolved Hide resolved
azurerm/internal/services/frontdoor/frontdoor_resource.go Outdated Show resolved Hide resolved
website/docs/r/frontdoor.html.markdown Outdated Show resolved Hide resolved
luigibk and others added 2 commits July 17, 2020 09:00
Co-authored-by: WS <20408400+WodansSon@users.noreply.github.com>
@timja
Copy link
Contributor

timja commented Jul 17, 2020

I tried fixing it for you but I was denied permission to push to your fork.

https://github.community/t/how-can-we-enable-allow-edits-from-maintainers-by-default/2847/7
This was submitted from our org account, which apparently doesn't support the option to allow maintainers to push

We'll keep that in mind in future, for now if you have any follow up changes you want to do yourself feel free to send us a PR and we'll merge it in

@ghost ghost removed the waiting-response label Jul 17, 2020
@luigibk
Copy link
Contributor Author

luigibk commented Jul 17, 2020

@WodansSon thanks for your review and comments. I have merged all of them but one and left a comment about the suggestion of adding a front_door_id.

@WodansSon
Copy link
Collaborator

I tried fixing it for you but I was denied permission to push to your fork.

https://github.community/t/how-can-we-enable-allow-edits-from-maintainers-by-default/2847/7
This was submitted from our org account, which apparently doesn't support the option to allow maintainers to push

We'll keep that in mind in future, for now if you have any follow up changes you want to do yourself feel free to send us a PR and we'll merge it in

Ahhh... that makes sense, thanks for the heads up. Yes, there are two things I think still need to be addressed:

  1. The read timeout, I left a new comment on the revert. I think your fork might be behind origin/master cause I changed the read time out in azurerm_frontdoor - Fix timeout for read operation to match documentation #7408
  2. I replied to you question about using front door ID vs. frontend endpoint ID in the PR proper.

Thanks again, this is so close, just a couple of tweaks and it will be ready to merge. Thanks!

@timja
Copy link
Contributor

timja commented Jul 20, 2020

  1. The read timeout, I left a new comment on the revert. I think your fork might be behind origin/master cause I changed the read time out in azurerm_frontdoor - Fix timeout for read operation to match documentation #7408

Hi @WodansSon
It seems that your timeout PR was reverted? #7485

@luigibk
Copy link
Contributor Author

luigibk commented Jul 20, 2020

About the read timeout, it's currently set at 5minutes in frontdoor:

https://github.com/terraform-providers/terraform-provider-azurerm/blob/master/azurerm/internal/services/frontdoor/frontdoor_resource.go#L37

and changing it to 5 hours breaks this test:

https://github.com/terraform-providers/terraform-provider-azurerm/blob/master/azurerm/internal/provider/provider_test.go#L77

so I have left those timeouts at 5 minutes for now

@luigibk
Copy link
Contributor Author

luigibk commented Jul 21, 2020

@WodansSon thanks for helping with this. I have just pushed the change related to replacing frontdoor_name and frontend_endpoint_name with the frontend_endpoint_id.

@WodansSon
Copy link
Collaborator

About the read timeout, it's currently set at 5minutes in frontdoor:

https://github.com/terraform-providers/terraform-provider-azurerm/blob/master/azurerm/internal/services/frontdoor/frontdoor_resource.go#L37

and changing it to 5 hours breaks this test:

https://github.com/terraform-providers/terraform-provider-azurerm/blob/master/azurerm/internal/provider/provider_test.go#L77

so I have left those timeouts at 5 minutes for now

It looks like Tom over wrote my change and reverted the value back to 5 minutes, so this is fine. Can we make sure the documentation also reflects this change?

@WodansSon
Copy link
Collaborator

image

@WodansSon WodansSon added this to the v2.20.0 milestone Jul 22, 2020
Copy link
Collaborator

@WodansSon WodansSon left a comment

Choose a reason for hiding this comment

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

@luigibk this LGTM now! 🚀

@WodansSon WodansSon merged commit e6a276c into hashicorp:master Jul 22, 2020
WodansSon added a commit that referenced this pull request Jul 22, 2020
@luigibk luigibk deleted the frontdoor-custom-https branch July 22, 2020 23:28
@ghost
Copy link

ghost commented Jul 23, 2020

This has been released in version 2.20.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 = "~> 2.20.0"
}
# ... other configuration ...

@ghost
Copy link

ghost commented Aug 21, 2020

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 👉 hashibot-feedback@hashicorp.com. Thanks!

@ghost ghost locked and limited conversation to collaborators Aug 21, 2020
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.

frontdoor custom_https_configuration can't update certificate
4 participants