Skip to content

make Firewall Policy Association mutable #9495

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

Conversation

modular-magician
Copy link
Collaborator

Current result of exploration on this issue: using the replaceExistingAssociation parameter, the resource is able to be updated following the expected paradigm i.e. the fine grained firewall_policy_association is not actually updated, but a new association is added to a different firewall policy, and given a flag allowing it to "steal" the attachment target from the existing association to previous firewall policy. If a lifecycle.create_before_destroy flag is set on the firewall policy, and an immutable characteristic is changed, the operations will successfully process for creating a new firewall policy, and updating the association without introducing a gap in policy-association uptime.

However there are problems with this straight forward approach:

  • if the replaceExistingAssociation addition fails, the resource breaks within Terraform due to some unseen change in the API end. The "existing association" will no longer be reachable, despite still existing. I was unable to determine why this is the case, but all operations on the resource will fail with the following message: "Error 400: Invalid value for field 'name': '{{name}}'. An association with that name does not exist., invalid". While existing infrastructure is undamaged, this will force the resource to be removed from state.
  • when a replaceExistingAssociation operation succeeds, temporarily the existing association persists, which can cause the older firewall policy to fail to delete. this does not cause a critical failure, as the policy can be deleted on a retry soon afterward
  • lastly, these do not mitigate the ability to cause the original critical failure, as without a "create before destroy" being configured, the original delete-delete-create-create steps can still occur and fail

The following config can be used to demo the swapover scenarios, replacing {{organization}} with your local test org:
https://paste.googleplex.com/4641467795243008

Release Note Template for Downstream PRs (will be copied)

See Write release notes for guidance.

compute: update support has been added for the `firewall_policy` field in `google_compute_firewall_policy_association` resource. It is recommended to only perform this operation in combination with a protective lifecycle tag such as "create_before_destroy" or "prevent_destroy" on your previous `firewall_policy` resource in order to prevent situations where a target attachment has no associated policy.

Derived from GoogleCloudPlatform/magic-modules#13078

Co-authored-by: Cameron Thornton <[email protected]>

[upstream:061323912ec1d7b062d0e2534829476c20573975]

Signed-off-by: Modular Magician <[email protected]>
@modular-magician modular-magician requested a review from a team as a code owner March 6, 2025 20:40
@modular-magician modular-magician merged commit 4371be1 into hashicorp:main Mar 6, 2025
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant