diff --git a/RELEASE_NOTES.md b/RELEASE_NOTES.md index 1afc3bc..bfcb9cb 100644 --- a/RELEASE_NOTES.md +++ b/RELEASE_NOTES.md @@ -3,7 +3,7 @@ ### Database Resource Changes The Multi-Region support feature has changed the Terraform resource structure for Databases. -Specifically, the "region" field has been renamed to "regions", and is now an array of strings, +Specifically, the `region` field has been renamed to `regions`, and is now an array of strings, as opposed to a single string. When updating the plugin from 1.x to 2.x, you will have to perform a manual Terraform state migration in order to keep existing databases under Terraform plugin management. @@ -11,13 +11,13 @@ plugin management. Please follow the below steps to migrate your configurations: For each Datatbase under Terraform management: -1. Obtain the database id (ex. b3107622-429d-45ab-a6da-0252cb091c86) -2. Obtain the Terraform resource name for the database (ex. "my_db", from the resource line in your Terraform .tf file) +1. Obtain the database id (ex. `b3107622-429d-45ab-a6da-0252cb091c86`) +2. Obtain the Terraform resource name for the database (ex. `my_db`, from the resource line in your Terraform `.tf` file) 3. Remove the database from the Terraform state ```sh terraform state rm astra_database.my_db ``` -4. Edit your Terraform resource file and convert the "region" field to "regions, and the value from a string to an array +4. Edit your Terraform resource file and convert the `region` field to `regions`, and the value from a *string* to an *array* ```sh region = "us-east1" ``` @@ -33,7 +33,7 @@ to ```sh terraform show ``` -which should show that the deployed "region" is now a "regions" attribute with a list of a single string. +which should show that the deployed `region` is now a `regions` attribute with a list of a single string. ### Database Data Source changes @@ -41,7 +41,7 @@ If you define any external Astra Database Data Sources, you will need to update as well. The same change made in the Resource schema has been made in the Data Source schema. However, for Data Sources, you only need to remove the definition, apply, then re-add the definition and apply again. -1. Comment out (or remove) any "data" definitions for Astra databases in your Terraform files. +1. Comment out (or remove) any `data` definitions for Astra databases in your Terraform files. ```sh #data "astra_database" "my_ext_db" { # database_id = "b3107622-429d-45ab-a6da-0252cb091c86" @@ -51,7 +51,7 @@ Data Sources, you only need to remove the definition, apply, then re-add the def ```sh terraform apply ``` -3. Re-add the "data" definition. +3. Re-add the `data` definition. ```sh data "astra_database" "my_ext_db" { database_id = "b3107622-429d-45ab-a6da-0252cb091c86" @@ -66,18 +66,18 @@ Data Sources, you only need to remove the definition, apply, then re-add the def ### Multi-Region Notes As of version 2.0.0, the Astra provider now supports deploying to multiple regions. This can be done in a -single Terraform apply (with all regions specified in the "regions" array when creating your Astra database), +single Terraform apply (with all regions specified in the `regions` array when creating your Astra database), or with an incremental approach (by creating your database with 1 region in the array and then adding new regions one by one). However, there are a few caveats: #### Terminating a Database with Multiple regions Currently, there is a bug in Astra that doesn't allow for a database to be terminated if the database has more than one datacenter in multiple regions. If you try to remove a database that has multiple regions, it -may get stuck in the MAINTENANCE or TERMINATING states. To avoid this, you should apply changes to your -database so that it only has a single region and is ACTIVE before attempting to terminate the database. +may get stuck in the `MAINTENANCE` or `TERMINATING` states. To avoid this, you should apply changes to your +database so that it only has a single region and is `ACTIVE` before attempting to terminate the database. #### Importance of the First Region -The first region defined in your database "regions" definition will be the region that the database is +The first region defined in your database `regions` definition will be the region that the database is initially created in. While you can add multiple regions, you can NOT remove the initial region, even if your database is successfully deployed to another region. If you no longer want your database to be deployed to this initial region, you must delete the database and recreate it in your other desired region(s). This diff --git a/docs/resources/database.md b/docs/resources/database.md index e6a1579..ced970c 100644 --- a/docs/resources/database.md +++ b/docs/resources/database.md @@ -17,7 +17,7 @@ resource "astra_database" "example" { name = "name" keyspace = "keyspace" cloud_provider = "gcp" - region = "us-east1" + regions = ["us-east1"] } ``` diff --git a/internal/provider/data_source_databases.go b/internal/provider/data_source_databases.go index c3600b6..d60cae7 100644 --- a/internal/provider/data_source_databases.go +++ b/internal/provider/data_source_databases.go @@ -60,10 +60,13 @@ func dataSourceDatabases() *schema.Resource { Type: schema.TypeString, Computed: true, }, - "region": { - Description: "The cloud provider region", - Type: schema.TypeString, + "regions": { + Description: "List of cloud provider supported regions", + Type: schema.TypeList, Computed: true, + Elem: &schema.Schema{ + Type: schema.TypeString, + }, }, "status": { Description: "The status",