Add support for Cloud Bigtable replication

[mbrukman]

Currently, support for Cloud Bigtable assumes a 1:1 correspondence between instances and clusters, which was true up until recently, when we launched support for replication (see blog post).

In the docs, an instance and a cluster are configured together, and assumes that there is exactly 1 of each instance and cluster created together:

resource "google_bigtable_instance" "instance" {
  name         = "tf-instance"
  cluster_id   = "tf-instance-cluster"
  zone         = "us-central1-b"
  num_nodes    = 3
  storage_type = "HDD"
}

What we need to do is enable configuring an instance (an abstract container) together with a list of clusters, each of which has a unique cluster id (so it could actually be a map as well).

In fact, the list of clusters is how it's implemented in the CreateInstanceRequest proto (note: ignore the comment about "exactly 1 cluster" per instance; that will be fixed soon).

[emilymye]

To document, this requires:

• Updating bigtable go lib to v2
• Changing google_bigtable_instance schema to have cluster schema block (possibly a breaking change)

[abennett]

What is the recommended method of updating the bigtable go library? Manually copy it over from the repo into the vendor directory? Should this be using dep?

[paddycarver]

@mbrukman can you confirm that the note in the API docs for creating an instance about clusters ("Currently exactly one cluster must be specified.") is incorrect? If so, does the API request not care about the number of clusters at all, or does it need 1 or more? And is there any difference between creating the clusters with the instance and creating the clusters using the clusters API?

I'd love any clarification so we can get this design right.

[mbrukman]

@paddycarver wrote:

@mbrukman can you confirm that the note in the API docs for creating an instance about clusters ("Currently exactly one cluster must be specified.") is incorrect? If so, does the API request not care about the number of clusters at all, or does it need 1 or more?

Sorry, that documentation page is out of date and needs to be re-generated. The source proto has the correct text: "Currently, at most two clusters can be specified."

And is there any difference between creating the clusters with the instance and creating the clusters using the clusters API?

No, the resulting clusters are the same. So you can either:

• create an instance with a single cluster and add a cluster afterwards
• create an instance from scratch with two clusters

@garye, @dmmcerlean — please correct me if I'm wrong.

[garye]

The resulting clusters are the same regardless of creating one at a time or both together, but the behavior of the default application profile is different. If both clusters are created at once, the profile will be set up for multi-cluster routing. Otherwise, it will be set up for single-cluster routing to the original cluster that was created via CreateInstance.

[paddycarver]

This was resolved in #2161, I believe.

[rileykarson]

I think we have the right shape for replication now, but didn't implement it yet because we were only making the breaking change for 1.19.

Edit: I don't believe this is a breaking change anymore - removing that tag.

[ghost]

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!