Rdb: Allow RDB instance upgrade to HA without replacing the resource

[paulez]

This is to allow converting an RDB instance to HA without recreating the resource.

This PR also contains minor fixes to the user_name and password fields which cannot be modified using the RDB instance API.

I plan on creating dedicated resources to manage users and databases in an upcoming PR.

To test I modified the acceptance test to also include an HA upgrade. This change will increase the test runtime by about 10 minutes, we can revert it if that’s too much of a time penalty.

The whole test suite timed-out because of an unrelated issue, so I ran the Rdb acceptance tests only with the following:

~/github/terraform-provider-scaleway/scaleway% time TF_ACC=1 go test -v . -run "TestAccScalewayRdb*" -timeout=30m 
=== RUN   TestAccScalewayRdbInstanceBeta
=== PAUSE TestAccScalewayRdbInstanceBeta
=== CONT  TestAccScalewayRdbInstanceBeta
--- PASS: TestAccScalewayRdbInstanceBeta (947.60s)
PASS
ok  	github.com/terraform-providers/terraform-provider-scaleway/scaleway	947.610s
TF_ACC=1 go test -v . -run "TestAccScalewayRdb*" -timeout=30m  5,87s user 1,47s system 0% cpu 15:49,36 total

[Sh4d1]

imho we should add a separate user resource, and if db creation with no user is not on the table, we should at least handle the update here, not a new resource

[jerome-quere]

Agreed that splitting the user to a separate resource makes more sens in TF. This would imply allowing the creation of the database without any user in the API or silently deleting it in the TF create

[paulez]

I am planning on adding a separate user resource in an upcoming PR.

I am concerned about allowing user changes in the instance resource as it could potentially conflict with definition in the user resource.

For example in this template definition (after adding a user object):

resource scaleway_rdb_instance_beta db {
  name = "test-terraform"
  node_type = "db-dev-m"
  engine = "PostgreSQL-11"
  is_ha_cluster = true
  user_name = "admin"
  password = "azerty"
}

resource scaleway_rdb_user_beta db_admin {
  instance_id = scaleway_rdb_instance_beta.db.id
  name = "toto"
  password = "R34lP4sSw#Rd"
  is_admin = true
}

We don’t want to have a confusion on which password is used, so I want to set the expectation that the password in the user definition "always win", which is only possible if we don’t allow updates on the instance resource. As such the user password is always updated to the user object definition after the instance is created.

[paulez]

This is the PR to add a specific resource for database users #520

[jerome-quere]

This is out of this MR but when reading it this field name seems strange, IMHO enable_ha_cluster would make more sense don't you think ?

[paulez]

It would make more sense indeed. is_ha_cluster is what is being used currently in the CreateInstance API.

So I am balancing using a better name vs keeping the attribute name in sync with the API and dealing with renaming an attribute without breaking compatibility.

I am more inclined to keep it as is for now, what do you think?

[kindermoumoute]

IMO it makes more sense to write enable_ha_cluster = true in the HCL:is_ha_cluster is the read only name of the property through the API, whereas enable_ha_cluster is an actionnable attribute in the terraform config.

[paulez]

Sounds good, I'll update this in a separate PR.

[kindermoumoute]

What issue did you encounter?

[paulez]

This is an issue on RDB side. I will remove this when it is resolved.

[kindermoumoute]

LGTM

[Sh4d1]

LGTM

[kindermoumoute]

Thanks for your contribution! @paulez 🙏