resource/cloudflare_ruleset: improve dashboard collisions #1393
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jacobbednarz
force-pushed
the
smoother-existing-rulesets-handling
branch
2 times, most recently
from
449fe21 to
3d1900b
Compare
|
acceptance tests are still passing |
|
cc @zakcutner @uhthomas if you're interested |
uhthomas
reviewed
Jan 17, 2022
| } | ||
|
|
||
| rules, err := buildRulesetRulesFromResource(d) | ||
| if err != nil { | ||
| return errors.Wrap(err, fmt.Sprintf("error building ruleset from resource")) | ||
| return errors.Errorf("error building ruleset rules from resource: %s", err) |
There was a problem hiding this comment.
fmt.Errorf and %w?
Same comment applies for other modifications in the file.
There was a problem hiding this comment.
I originally took this approach and I ended up with a circular %w directive can only be used in Errorf style error despite using Errorf! I’ll have another dig into this tomorrow after ☕ and see if I can make sense of it. Otherwise, we’ll roll with this as it works.
One of the earliest niggles with customers coming from the dashboard to Terraform was the collision caused by a Ruleset phase being created in the UI but the Terraform provider also needing to create the same phase. This was problematic for a few reasons: - The first was that when you deleted Ruleset rules in the UI, it didn't remove the phase. This was intentional but hidden behind the UI and only accessible via the API. - Secondly, when customers wanted to use Terraform, there was an assumption they would be starting from scratch and many were not. - Finally, in the event of a collision, we didn't know which Ruleset the customer wanted to use so we error'd out with a link to manually resolve which isn't a great solution but made the issue more prominent. I had a chance to rethink through this issue and managed to find a way that we improve all three points above and remove majority of the pain points. With the proposed changes, the only time a customer needs to manually resolve the Ruleset rules is if there are existing rules in the UI which requires them to be deleted or migrated. Achieving this requires the assumption that if the Ruleset has no rules, it is ok to modify. Unfortunately, it's not that simple in practice. If the phase already exists, we cannot just update it as the `name` attribute is not writable after creation. Along with this, the `ref` and `version` values will be automatically incremented causing a permadiff in Terraform as the customer hasn't actually modified these values but the backing service (and API) has. To work around this, if we find a phase with no rules, we recreate it with the provided values which is essentially the same the same thing as the "happy path" for a new Terraform resource would be anyway.
jacobbednarz
force-pushed
the
smoother-existing-rulesets-handling
branch
from
3d1900b to
7dc1827
Compare
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
One of the earliest niggles with customers coming from the dashboard to
Terraform was the collision caused by a Ruleset phase being created in
the UI but the Terraform provider also needing to create the same
phase. This was problematic for a few reasons:
remove the phase. This was intentional but hidden behind the UI and
only accessible via the API.
assumption they would be starting from scratch and many were not.
customer wanted to use so we error'd out with a link to manually
resolve which isn't a great solution but made the issue more
prominent.
I had a chance to rethink through this issue and managed to find a way
that we improve all three points above and remove majority of the pain
points. With the proposed changes, the only time a customer needs to
manually resolve the Ruleset rules is if there are existing rules in the
UI which requires them to be deleted or migrated.
Achieving this requires the assumption that if the Ruleset has no rules,
it is ok to modify. Unfortunately, it's not that simple in practice. If
the phase already exists, we cannot just update it as the
nameattribute is not writable after creation. Along with this, the
refandversionvalues will be automatically incremented causing a permadiffin Terraform as the customer hasn't actually modified these values but
the backing service (and API) has. To work around this, if we find a
phase with no rules, we recreate it with the provided values which is
essentially the same the same thing as the "happy path" for a new
Terraform resource would be anyway.