Open mbrancato opened 5 months ago
Based on the API, this appears to be something that can be accomplished simply with a new field. There could be additional considerations needed for handling the upgrade without recreating the instance, but I can't quite tell from the API alone.
I have tried to implement what this issue would expect, but it seems that it is not possible to create a Cloud SQL instance with the old network architecture. This is a blocker for implementing this feature from a testability perspective.
@marblejenka purely for testing the behavior, you may be able to use one of the networks in our test environment that are older (for example, the default
network is from 2017; let me know if you need another option though). However, it does look like a test like this would eventually begin failing (at some point), so I would probably recommend writing a test that is skipped. That way, we know what it should be doing and how it can be tested, but we don't need to rely on old networks being kept around in our continuous test environments.
Community Note
Description
Creating a CloudSQL instance on an older VPC will result in the CloudSQL instance getting the "old" network architecture. This prevents using the database instance with other Google cloud services such as Vertex AI, Looker, etc. There is a process to upgrade the network architecture using
gcloud
, but it can also be set via the REST API.The API uses the enum values:
All of this is described in the following documentation: https://cloud.google.com/sql/docs/postgres/upgrade-cloud-sql-instance-new-network-architecture
New or Affected Resource(s)
Potential Terraform Configuration
References
No response
b/329495078