Create the "reverse and resume" function within the google provider

[bones108]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
• Please do not leave +1 or me too comments, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.
• If an issue is assigned to a user, that user is claiming responsibility for the issue.
• Customers working with a Google Technical Account Manager or Customer Engineer can ask them to reach out internally to expedite investigation and resolution of this issue.

Description

At this time, the google_netapp_volume_replication resource does not allow for the reversal of replication via the provider. At this time, NetApp posted that this should be done via the console.

Since reverse and resume can be done via gcloud, this would suggest that the APIs are available to instrument against via the provider. Can this feature be added to the provider so that we perform this function via PR to our Terraform IaC repository?

New or Affected Resource(s)

• google_netapp_volume_replication

Potential Terraform Configuration

References

No response

b/378507740

[SarahFrench]

Note from triage: we'd be happy to support 'promote' actions in Terraform, but are unsure about supporting 'reverse and resume'. That action is too imperative to fit into Terraform's declarative way of managing resources. We'd be open to seeing proposed config for that user flow though.

[SarahFrench]

Forwarding to the service team for their input on the request. If we proceeded with this we'd expect some design docs describing the approach.

[okrause]

An API for reverse and resume is available and could theoretically be used by TF. The problem is that the resource model and the way the API works if pretty imperative and doesn't lend very well to the declarative way TF manages resources. Just a few examples:

• API to create a replication is triggered in the source volume. It creates a child replication resource on the source volume. It takes destination volume parameters and creates a destination volume, which IS NOT under TF management (Does TF have a concept to accommodate two resources being created when only creating one resource?).
• As long as replication between source and destination volume is in mirrored state, any update done to one of them is also done to the other one. Again, if the dest volume would be under TF management, the execution plan of TF would get very confused if changes to one resource would also trigger changes to the other resource. Users would need to keep them in sync manually or will experience an interesting game of setting ping-pong.
• The replication resource is a child of the source volume. TF will send all API calls to source region. If source region becomes available entirely, API calls to source region may fail. We would need API calls to the destination volume in the destination region to manage the replication child resource of the source volume in source region. This would require a lot of complex custom code which will likely be fragile.
• To do a reverse and resume, the TF provider needs to send an reverse and resume API call to do destination volume it doesn't know about specifying a resource which is a child of the source volume ** and we need to find a non-breaking way to make this functionality available to users in a way users cannot get the direction wrong. We did put lot A LOT of effort into UI and documentation to caution the user on getting directions right, since getting them wrong my lead to unintentionally discarding user data. Just hiding all of that behind a "direction" parameter or similar makes me very nervous that the user may make mistakes.

Due to these reasons (and likely more I forgot meanwhile), we decided to make reverse resume a very explicit user action (drop replication resource state and import replication resource from destination volume) to unmistakably express the users intend. Since this is a very rare action, we consider this a fair trade-off.