page_rules: Swap to completely replacing rules

[jacobbednarz]

For a long time, this provider relied on sending page rules using
cloudflare-go's ChangePageRule which was documentated to allow inline
updates using a PATCH request. Until recently, this wasn't the case and
it actually mimicked the PUT alternative (UpdatePageRule) where it
attempted to replace the entire rule. This was fixed and while you
could now send inline updates to actions, there wasn't a way to remove
them once they were there. To address this, I've swapped back to
UpdatePageRule (the PUT request) which will resolve the aforementioned
issue with removing rules but it does re-introduce the caveat of not
being able to manage actions that require a Solutions Engineer. This
means, you can't manage them using this endpoint as you won't have
permission to apply them. This extends to page rule changes like
re-ordering or updating other actions which are in the same rule. If you
hit this use case, you should move the cache key into Cloudflare
Workers.

This commit backs out most of the changes from c1799f4 as they are no
longer required for differentiating the actions to send but it does
introduce some changes to the way we determine whether or not we send
browser_cache_ttl and edge_cache_ttl based on some issues
encountered with their default values. It now performs a HasChange on
their values to help determine whether or not they should be a part of
the payload.

Closes #198
Closes #265

[jacobbednarz]

We're also green on integration tests now.

=== RUN   TestAccCloudflarePageRule_Import
=== PAUSE TestAccCloudflarePageRule_Import
=== RUN   TestAccCloudflarePageRule_Basic
--- PASS: TestAccCloudflarePageRule_Basic (4.13s)
=== RUN   TestAccCloudflarePageRule_FullySpecified
--- PASS: TestAccCloudflarePageRule_FullySpecified (4.25s)
=== RUN   TestAccCloudflarePageRule_ForwardingOnly
--- PASS: TestAccCloudflarePageRule_ForwardingOnly (3.66s)
=== RUN   TestAccCloudflarePageRule_ForwardingAndOthers
--- PASS: TestAccCloudflarePageRule_ForwardingAndOthers (0.02s)
=== RUN   TestAccCloudflarePageRule_Updated
--- PASS: TestAccCloudflarePageRule_Updated (6.15s)
=== RUN   TestAccCloudflarePageRule_CreateAfterManualDestroy
--- PASS: TestAccCloudflarePageRule_CreateAfterManualDestroy (6.35s)
=== RUN   TestAccCloudflarePageRule_UpdatingZoneForcesNewResource
=== RUN   TestAccCloudflarePageRuleMinifyAction
--- PASS: TestAccCloudflarePageRuleMinifyAction (4.71s)
=== CONT  TestAccCloudflarePageRule_Import
--- PASS: TestAccCloudflarePageRule_Import (6.14s)
PASS
PASS	github.com/terraform-providers/terraform-provider-cloudflare/cloudflare	35.441s

[patryk]

Thank you @jacobbednarz, merged!

[grogancolin]

Hi @jacobbednarz @patryk - I understand your reasoning on this, however I do feel it's a mistake that this provider explicitly backs out of managing specific page rules.

Not all organisations use workers, and assuming we can and should isn't something that the provider should be forcing on end users.

For our Page Rule configuration, this PR breaks completely our ability to manage them via code.

[jacobbednarz]

@grogancolin I totally sympathise with you. This wasn't just a decision based on what made my maintainer life easier as internally, we are facing the issues both you and I have outlined in these PRs.

• We have custom cache keys in page rules
• We don't use Workers
• We manage everything in code

One thing that helped make this decision was that up until about three months ago, this behaviour was consistent regardless of whether we used the PATCH or PUT endpoint (due to a regression in the API). We've been lucky enough that the number of page rules we're changing on the zones has really slowed down and importing from what changes are made in the UI is sufficient. This doesn't mean by any means that I'm settling for this; it just means I've opted for the masses and not the minority to allow bandwidth for focusing on the issue.

I will open a new issue with the current state of affairs and see if we can brainstorm some potential work arounds for the Cloudflare API (trying to handle it in the provider isn't really viable) and drag in the Cloudflare folks for their 2c. WDYT?

[grogancolin]

@jacobbednarz - apologies I didn't get back to you on this.

I will open a new issue with the current state of affairs and see if we can brainstorm some potential work arounds for the Cloudflare API (trying to handle it in the provider isn't really viable) and drag in the Cloudflare folks for their 2c. WDYT?

I think that's a fair position - however it would be good to give it more urgency as this is a regular irritant for us.

Any updates on the current state of affairs?

Anything I can do to help with the task? Obviously I can't modify Cloudflare's APIs but I can and am more than willing to work on the provider to keep this issue moving in the right direction.