Skip to content
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

Merged
merged 6 commits into from
Aug 11, 2017

Conversation

rileykarson
Copy link
Collaborator

@rileykarson rileykarson commented Aug 9, 2017

Add support for instance_type to google_bigtable_instance.

edit: linking #263


Breaking change: num_nodes needs to be unset for DEVELOPMENT instances, and >3 for PRODUCTION ones. I removed the default, which will cause diffs for users that relied on the implicit 3 nodes.

We could avert it by keeping the default - this means DEVELOPMENT users will need to explicitly specify 0 instead of not needing to specify num_nodes at all.

Type: schema.TypeInt,
Type: schema.TypeInt,
Optional: true,
ForceNew: true,
Copy link
Contributor

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.

Copy link
Collaborator Author

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.

Copy link
Contributor

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...

Copy link
Collaborator Author

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.

@rileykarson
Copy link
Collaborator Author

TF_ACC=1 go test ./google -v -run=TestAccBigtable -timeout 120m
=== RUN   TestAccBigtableInstance_basic
--- PASS: TestAccBigtableInstance_basic (4.91s)
=== RUN   TestAccBigtableInstance_development
--- PASS: TestAccBigtableInstance_development (4.31s)
=== RUN   TestAccBigtableTable_basic
--- PASS: TestAccBigtableTable_basic (6.10s)
=== RUN   TestAccBigtableTable_splitKeys
--- PASS: TestAccBigtableTable_splitKeys (6.73s)
PASS
ok  	github.com/terraform-providers/terraform-provider-google/google	22.203s

@rileykarson rileykarson merged commit 5645f72 into hashicorp:master Aug 11, 2017
z1nkum pushed a commit to z1nkum/terraform-provider-google that referenced this pull request Aug 15, 2017
…#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
negz pushed a commit to negz/terraform-provider-google that referenced this pull request Oct 17, 2017
…#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
chrisst pushed a commit to chrisst/terraform-provider-google that referenced this pull request Nov 9, 2018
…#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
luis-silva pushed a commit to luis-silva/terraform-provider-google that referenced this pull request May 21, 2019
<!-- This change is generated by MagicModules. -->
/cc @rileykarson
@ghost
Copy link

ghost commented Mar 31, 2020

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!

@ghost ghost locked and limited conversation to collaborators Mar 31, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants