Add support_physical_cluster_replication field to cluster creation #261
Conversation
| "support_physical_cluster_replication": schema.BoolAttribute{ | ||
| Optional: true, | ||
| Computed: true, | ||
| Description: "Specifies whether a cluster should be started using an architecture that supports physical cluster replication.", |
There was a problem hiding this comment.
Do we have any documentation to suggest why a customer wouldn't want this set to true? Otherwise why wouldn't everyone set it to true? @kathancox this is probably more of a docs concern.
There was a problem hiding this comment.
I guess we should also say it's defaulting to false.
| if cfg.SupportPhysicalClusterReplication.ValueBool() { | ||
| dedicated.SupportPhysicalClusterReplication = ptr(cfg.SupportPhysicalClusterReplication.ValueBool()) | ||
| } |
There was a problem hiding this comment.
It looks like if someone were to actually set the value to false, SupportPhysicalClusterReplication would be omitted from the request. I think we want it to to pass an explicit false in that case. Otherwise, once we start defaulting to true on the serverside the false pass via terraform will be ignored.
| Optional: true, | ||
| Computed: true, |
There was a problem hiding this comment.
Normally when we have optional values, we'll let the server choose the default. computed: true, would normally allow the value in the state to be set by what the server chose. That way from provider version to version we could change the default on the server and it would remain working with our serverside default. However, I suggested we not add the field to the cluster response in that recent PR. I think that is a bit problematic with the current implementation here. I see 2 options:
- we have a hard default of false that's built into the provider for this version. That won't feel very ideal when we change the serverside default to true because people will probably forget to pass this optional parameter and end up with false. We could change the default in a later terraform version but it would be a breaking change to the provider.
- we follow through with adding a value to the cluster response that indicates which value was chosen.
Commit checklist
make generate)