-
Notifications
You must be signed in to change notification settings - Fork 246
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
Private SQLInstance and private network cannot be created in the same set of configs. #148
Comments
Hi @AlexBulankou, are you able to consistently reproduce this issue? I applied your YAML verbatim just now, and both my |
A related issue we face (also seen in some Terraform forums) is that we cannot create two private CloudSQL instances if it's your first time. This is because after you set up private service networking, the first CloudSQL instance opens up a new peering connection, so any additional instances will "fail to create" if it's done simultaneously. |
@tonybenchsci, thanks for bringing this up -- we'll look into this. In the meantime, I will open a separate GitHub issue to track this scenario specifically. Would you happen to have YAML snippets we can use to reproduce your issue? It would be helpful to include in the new GitHub issue. |
@jcanseco, if you check the status of SQLInstance, what is it? Mine shows $ gcloud sql instances list
NAME DATABASE_VERSION LOCATION TIER PRIMARY_ADDRESS PRIVATE_ADDRESS STATUS
mysql-private-instance MYSQL_5_7 us-central1-a db-f1-micro - - FAILED |
I also see this error when creating the private IP and SQL in the same run:
the sqlinstance resource in kubernetes shows as ready:
even though gcloud shows it as failed:
|
Yep, I have the same in 1.8.0: ready status in Kubernetes but failed - in gcloud. Recreating same instance but with different name several minutes later works fine. |
Hi all, thanks, we're looking into this issue. The gist is that if a Cloud SQL instance specifies a private network, an implicit dependency seems to be established between the Cloud SQL instance and the network's Service Networking Connection resource. This implicit dependency imposes a requirement where the Service Networking Connection must be created first before the Cloud SQL instance. This is quite a weird behavior. No real updates yet, but we're looking into it, and we'll keep you updated. |
Update in response to @tonybenchsci's earlier comment -- Cloud SQL is aware of this issue and we do not have an expected timeline for when it might be resolved. Our suggested workaround is, when creating a private SQLInstance on a network for the first time, wait for the creation of one instance first (make sure it's state is |
Hi all, apologies for the late update. The original issue where you couldn't create a private This will ensure that the This fix has been released as part of KCC v1.30.0. As for the related issue that @tonybenchsci raised up above, however, I regret to say that a proper fix from the Cloud SQL team is still pending. For now, we maintain our previous recommendation. |
We are trying to use |
Hi @rk185151. Please see my comment here. I believe that is what you're looking for. |
Describe the bug
Private SQLInstance and private network cannot be created in the same set of configs.
ConfigConnector Version
1.7.0
To Reproduce
Create private networking and sql instance that depends on this network in the same set of yamls.
Expected: dependencies are resolved and network is created, then instance is created.
Actual: sql instance is stuck in the failed state and cannot be updated.
Workaround: create network, wait for it to be successfully created, then create sql instance.
YAML snippets:
The text was updated successfully, but these errors were encountered: