-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Support creating Database Migration Service connection profiles connected to existing Cloud SQL and AlloyDB instances #11484
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
Conversation
…inked to existing CSQL/AlloyDB instances.
…inked to existing CSQL/AlloyDB instances.
…inked to existing CSQL/AlloyDB instances.
…inked to existing CSQL/AlloyDB instances.
Hello! I am a robot. Tests will require approval from a repository maintainer to run. @BBBmau, a repository maintainer, has been assigned to review your changes. If you have not received review feedback within 2 business days, please leave a comment on this PR asking them to take a look. You can help make sure that review is quick by doing a self-review and by running impacted tests locally. |
…y/magic-modules into cp3" This reverts commit e54990c, reversing changes made to 6b302f9.
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR generated some diffs in downstreams - here they are.
|
Tests analyticsTotal tests: 8 Click here to see the affected service packages
Action takenFound 3 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected tests
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR generated some diffs in downstreams - here they are.
|
Tests analyticsTotal tests: 8 Click here to see the affected service packages
Action takenFound 3 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected tests
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR generated some diffs in downstreams - here they are.
|
Tests analyticsTotal tests: 8 Click here to see the affected service packages
Action takenFound 3 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected tests
|
|
|
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR generated some diffs in downstreams - here they are.
|
Tests analyticsTotal tests: 8 Click here to see the affected service packages
View the build log |
@BBBmau This PR has been waiting for review for 3 weekdays. Please take a look! Use the label |
@@ -266,25 +289,37 @@ properties: | |||
properties: | |||
- !ruby/object:Api::Type::String | |||
name: 'host' | |||
required: true | |||
required_with: |
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.
what's the reasoning behind replacing required
with required_with
? Is it necessary when the fields are already marked as required
?
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.
DMS started to support a new path, called existing-instance, for the following homogenous migration types:
- MySQL to Cloud SQL (MySQL)
- PostgreSQL to Cloud SQL (PostgreSQL)
- PostgreSQL to AlloyDB
With this new existing-instance path, users can create the destination database instance outside of DMS and then create DMS connection profiles that point to these destination instances. In that case, users need to provide only the CloudSQL ID or AlloyDB ID, and they don't need to provide additional connection params like username, password, host, etc.
For example, a destination connection profile for MySQL -> MySQL migrations will look like this:
resource "google_database_migration_service_connection_profile" "source" {
location = "us-central1"
…
mysql {
cloud_sql_id = "<csql_id>"
}
}
This means that connection params (e.g. username, password, etc.) are no longer required in all cases.
That said, for other migration types (e.g. Oracle -> PostgreSQL), it doesn't make sense to provide partial connection params, so we're configuring the resource so that if one connection param is provided (e.g. username), we'll need other params to be provided as well, and we're using the required_with to achieve that.
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.
Thank you for the thorough explanation! I also came across this which matches what you just explained: https://cloud.google.com/database-migration/docs/mysql/configure-source-database#overview-mysql
Support creating DMS connection profiles that link to existing Cloud SQL instances/AlloyDB clusters.
This will allow using such connection profiles as destination to the following migration types:
Release Note Template for Downstream PRs (will be copied)