-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Add support for instance_type to google_bigtable_instance. #313
Add support for instance_type to google_bigtable_instance. #313
Conversation
Type: schema.TypeInt, | ||
Type: schema.TypeInt, | ||
Optional: true, | ||
ForceNew: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the number of nodes is ForceNew
, we don't want to force our users to delete and recreate their production database.
I would rather have our users specify num_nodes = 1 for DEVELOPMENT.
If you don't send num_nodes to the server, does it set 1 for dev and 3 for production by default? If so, we could use Computed = True
for num_nodes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we send a non-zero value to the server for num_nodes
for a DEVELOPMENT
instance, the request fails. There's no server default when you don't send a num_nodes
for a production one; the request fails.
Users won't actually need to recreate their instances; the num_nodes
of 3 is preserved in state, and they will just need to update their config when it diffs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we leave the num_nodes
default to 3 and just don't send the property when creating a DEVELOPMENT
instance? This way, we don't create churn for our users...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doing things like that breaks the 1:1 mapping from config -> the API, and imo isn't worth it if we ever need to correct later. For example, if we were to gain the ability to read num_nodes
, we would either need to conditionally read it or would see diffs in the future.
I think it's worth a breaking change here because the number of users is small (and I expect the # of users that relied on the implicit default is smaller), the change is easy to make, and it means we'll be tracking the API as accurately as we can until the next client update.
|
…#313) * govendor fetch cloud.google.com/go/bigtable * Vendor the rest of the stuff. * Add support for instance_type to google_bigtable_instance. * Revendored some packages. * Removed bad packages from vendor.json
…#313) * govendor fetch cloud.google.com/go/bigtable * Vendor the rest of the stuff. * Add support for instance_type to google_bigtable_instance. * Revendored some packages. * Removed bad packages from vendor.json
…#313) * govendor fetch cloud.google.com/go/bigtable * Vendor the rest of the stuff. * Add support for instance_type to google_bigtable_instance. * Revendored some packages. * Removed bad packages from vendor.json
<!-- This change is generated by MagicModules. --> /cc @rileykarson
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! |
Add support for
instance_type
togoogle_bigtable_instance
.edit: linking #263
Breaking change:
num_nodes
needs to be unset forDEVELOPMENT
instances, and >3 forPRODUCTION
ones. I removed the default, which will cause diffs for users that relied on the implicit3
nodes.We could avert it by keeping the default - this means
DEVELOPMENT
users will need to explicitly specify0
instead of not needing to specifynum_nodes
at all.