-
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
Persist state from the API for google_sql_database_instance regardless of what attributes the user has set #208
Conversation
…s of what attributes the user has set
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.
Does reveal any hidden issues with our current acceptance tests, by way of drift of attributes that weren't previously being read?
} | ||
|
||
d.Set("ip_address", _ipAddresses) | ||
d.Set("settings", flattenSettings(instance.Settings)) |
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.
We generally recommend checking for errors from d.Set
when setting non scalar values like slices and maps.
if err := d.Set("settings", flattenSettings(instance.Settings)); err != nil {
log.Printf("[WARN] failed to set <...>")
}
Generally you want to log a WARN
and not actually error out here
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.
Done
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.
Generally looks good - I'm just curious why so much is computed, and have a line that needs to be moved in Create while you're here.
When running this interactively, it works for Postgresql, but we should also prove it using a test (or even better, both a normal + import test) since it looks like our documentation states that we support it. It's kind of unrelated to these changes, so I have no problem with that as a followup/issue if you don't want to clutter up this PR.
@@ -276,6 +290,7 @@ func resourceSqlDatabaseInstance() *schema.Resource { | |||
Type: schema.TypeBool, | |||
Optional: true, | |||
ForceNew: true, | |||
Computed: true, | |||
}, | |||
"master_heartbeat_period": &schema.Schema{ | |||
Type: schema.TypeInt, |
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.
While you're in this file, can you move the d.SetId() in Create to below the actual insert request? (~line 540 right now)
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.
Done
@@ -48,6 +48,7 @@ func resourceSqlDatabaseInstance() *schema.Resource { | |||
"activation_policy": &schema.Schema{ | |||
Type: schema.TypeString, | |||
Optional: true, | |||
Computed: 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.
It looks like we're setting a lot of values to Computed
, which worries me a bit because of what happens when you remove a value in config to get the default behaviour; where the resource will keep the last-set value for the field. How come we've had to make so much of this computed?
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.
A lot of the fields have defaults that come back from the API or have defaults that differ between first and second generation instances
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.
Thanks for clarifying! 👍
@catsby not really, but I think that's a good thing for a refactoring change like this. I did notice that we had no ability to remove blocks in an update so I made that change, although because of the bug with Computed+Optional (see the discussion in #committers-terraform from yesterday) they don't really work the way they're supposed to anyway :-/ @rileykarson Yeah let's take that into a followup since this is big enough as it is. |
Following up with Postgres tests SGTM LGTM, merge at will 👍
|
…s of what attributes the user has set (hashicorp#208)
…s of what attributes the user has set (hashicorp#208)
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 👉 [email protected]. Thanks! |
Fixes #114.
Currently a WIP because tests are failing. Debug logs forTests are no longer failing, this is now ready for review.TestAccGoogleSqlDatabaseInstance_slave
at https://gist.github.com/danawillow/f5647fc7a78417eb99c536599742870b.