Manage DMS Destination Database created outside of DMS

[florenp]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment. If the issue is assigned to the "modular-magician" user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If the issue is assigned to a user, that user is claiming responsibility for the issue. If the issue is assigned to "hashibot", a community member has claimed the issue already.

Description

We want to be able to create google_database_migration_service_connection_profile for a destination database created outside of DMS.

New or Affected Resource(s)

google_database_migration_service_connection_profile

References

https://cloud.google.com/database-migration/docs/mysql/create-migration-job-intro#existing-instance https://cloud.google.com/database-migration/docs/release-notes#December_14_2023

b/320968251

[SarahFrench]

Hi @florenp - could you please provide some 'pseudocode' Terraform configuration to show how you'd expect the feature you're requesting would work? This would help us understand your request a bit better

[florenp]

Hello @SarahFrench

Something like that:

resource "google_database_migration_service_connection_profile" "cloudsqlprofile_destination" {
  location              = var.region
  connection_profile_id = var.display_name
  display_name          = var.display_name
  labels                = var.labels
  cloudsql {
    cloud_sql_id = google_sql_database_instance.main.id
  }
}

By the way the cloud_sql_id is already present but it's only an output today. https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/database_migration_service_connection_profile#nested_cloudsql

[SarahFrench]

Thanks, that's a big help!

The API documentation still has those fields marked as output only, so we cannot update the provider to allow users to supply those values. And the only field there that can be set by a user is cloudsql.settings, but if I understand things correctly that field creates a destination DB via DMS and instead you want to set the destination as a pre-existing DB that isn't made via that method.

The guide you shared describes how you can use pre-existing DBs as destinations when using the Console and gcloud CLI, but we'll need to wait for the new feature to also be added to the public API. Hopefully that will come soon!

I'll forward this ticket to the relevant service team so they're aware that this feature is currently blocked.

[florenp]

Hello @SarahFrench,

That's clear for me. We'll wait for the API change.

[florenp]

Hello @SarahFrench,

We manage to do it replacing the cloudsql block by a mysql or postgresql one.

resource "google_database_migration_service_connection_profile" "cloudsqlprofile_destination" {
  location              = var.region
  connection_profile_id = var.display_name
  display_name          = var.display_name
  labels                = var.labels
  mysql {
      host         = var.cloudsql_destination_ip
      port         = "3306"
      username     = var.user
      password     = var.password
      cloud_sql_id = google_sql_database_instance.main.id
    }
  }
}

But we have one command to execute manually to "demote" the CloudSQL instance:

• gcloud database-migration migration-jobs demote-destination job-test --region=${var.region}

Could it be automated within the provider?

[SarahFrench]

I'm not sure, and I think that's a call for the relevant service team (that this issue has been forwarded to).

The database migration API has an endpoint for demotion that could be called in cases where the plan shows a cloudsql block is removed. However, if I understand correctly, this process would 'orphan' the database that was originally created by the google_database_migration_service_connection_profile resource/the DMS service. It wouldn't be clear to a user what they'd need to manage that database after they swapped the cloudsql block for a different block type. Perhaps requiring the manual step that you're currently performing is a better choice versus users unknowingly having dangling resources in their projects that aren't managed by Terraform. I haven't used the migration service myself so this is just conjecture from me!

Did you need to run that demotion command before applying the plan that follows swapping cloudsql => mysql in the config? Or after?