Change authorized_networks to a Set

[rosbo]

Fixes #547 without changing the behavior of the update method (old style behavior where it tried as hard as possible to preserve changes that happened outside of Terraform, see #564).

[danawillow]

This is actually the default behavior, so you don't need this line (I'm fine either way if you want to leave it in to be explicit).

I do wonder whether it actually makes more sense to hash on something a bit more like a primary key, like the network value. Even though our update logic will be the same no matter which part of it changes, it's possible that someone could get confused if they see in a plan that the whole thing is changing rather than just the part of it they changed. What do you think?

[rosbo]

--- PASS: TestAccGoogleSqlDatabaseInstance_settings_basic (40.81s)
--- PASS: TestAccGoogleSqlDatabaseInstance_importBasic (50.12s)
--- PASS: TestAccGoogleSqlDatabaseInstance_basic (59.57s)
--- PASS: TestAccGoogleSqlDatabaseInstance_authNets (73.12s)
--- PASS: TestAccGoogleSqlDatabaseInstance_multipleOperations (74.13s)
--- PASS: TestAccGoogleSqlDatabaseInstance_basic2 (60.89s)
--- PASS: TestAccGoogleSqlDatabaseInstance_settings_downgrade (45.03s)
--- PASS: TestAccGoogleSqlDatabaseInstance_settings_upgrade (65.79s)
--- PASS: TestAccGoogleSqlDatabaseInstance_diskspecs (377.40s)
--- PASS: TestAccGoogleSqlDatabaseInstance_basic3 (419.98s)
--- PASS: TestAccGoogleSqlDatabaseInstance_importBasic3 (398.40s)
--- PASS: TestAccGoogleSqlDatabaseInstance_maintenance (459.13s)
--- PASS: TestAccGoogleSqlDatabaseInstance_dontDeleteDefaultUserOnReplica (644.16s)
--- PASS: TestAccGoogleSqlDatabaseInstance_slave (951.12s)

[danawillow]

GitHub appears to have eaten @rosbo's comment but it said:

I made it explicit because below (line 1056), we need to pass the hash function for the NewSet method and by making it explicit here, it is easier to see that both uses the same method.

The API does accept:

      authorized_networks {
        name = "stitchdata-3"
        value = "52.204.228.32/32"
        expiration_time = "2018-08-30T13:22:53.108Z"
      }
      authorized_networks {
        name = "stitchdata-3"
        value = "52.204.228.32/32"
        expiration_time = "2018-07-21T13:22:53.108Z"
      }

and keeps both entries...

Since the primary key used by the API is all three fields, I suggest we stick to the same key. If we don't, we would be more restrictive than the API which could prevent reasonable use cases that we are not necessary aware of.

[danawillow]

Looks like tests are failing in CI, can you take a look?

------- Stdout: -------
=== RUN   TestAccGoogleSqlDatabaseInstance_authNets
--- FAIL: TestAccGoogleSqlDatabaseInstance_authNets (50.86s)
    testing.go:434: Step 0 error: After applying this step, the plan was not empty:
        
        DIFF:
        
        UPDATE: google_sql_database_instance.instance
          settings.0.ip_configuration.0.authorized_networks.#:                          "0" => "1"
          settings.0.ip_configuration.0.authorized_networks.3898304677.expiration_time: "" => "2017-11-15T16:19:00.094Z"
          settings.0.ip_configuration.0.authorized_networks.3898304677.name:            "" => "misc"
          settings.0.ip_configuration.0.authorized_networks.3898304677.value:           "" => "108.12.12.12"
        
        STATE:
        
        google_sql_database_instance.instance:
          ID = tf-lw-1398641235381731251
          connection_name = hc-terraform-testing:tf-lw-1398641235381731251
          database_version = MYSQL_5_6
          ip_address.# = 1
          ip_address.0.ip_address = 173.194.104.164
          ip_address.0.time_to_retire = 
          master_instance_name = 
          name = tf-lw-1398641235381731251
          region = us-central
          replica_configuration.# = 0
          self_link = https://www.googleapis.com/sql/v1beta4/projects/hc-terraform-testing/instances/tf-lw-1398641235381731251
          settings.# = 1
          settings.0.activation_policy = ON_DEMAND
          settings.0.authorized_gae_applications.# = 0
          settings.0.backup_configuration.# = 1
          settings.0.backup_configuration.0.binary_log_enabled = false
          settings.0.backup_configuration.0.enabled = false
          settings.0.backup_configuration.0.start_time = 08:00
          settings.0.crash_safe_replication = false
          settings.0.database_flags.# = 0
          settings.0.disk_autoresize = false
          settings.0.disk_size = 0
          settings.0.disk_type = 
          settings.0.ip_configuration.# = 1
          settings.0.ip_configuration.0.authorized_networks.# = 0
          settings.0.ip_configuration.0.ipv4_enabled = true
          settings.0.ip_configuration.0.require_ssl = false
          settings.0.location_preference.# = 0
          settings.0.maintenance_window.# = 0
          settings.0.pricing_plan = PER_USE
          settings.0.replication_type = SYNCHRONOUS
          settings.0.tier = D0
          settings.0.version = 1
FAIL

[danawillow]

Although weirdly it looks like this didn't start failing until last night, so it might actually just be a coincidence.

[rosbo]

Looking into it

[rosbo]

I found the issue, there is an expiration time set in the test and the date is expiration_time = "2017-11-15T16:19:00.094Z" (yesterday)

[rosbo]

Fix is here: #754

[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 👉 [email protected]. Thanks!