generated from crossplane/provider-template
-
Notifications
You must be signed in to change notification settings - Fork 64
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
Mysql provider crashes when creating user #74
Labels
bug
Something isn't working
Comments
The attempted fix in #71 didn't solve it, working on a unit test now. |
2 tasks
Thanks for addressing this so fast @Duologic, I confirmed that the issue has been resolved. |
What version is this fixed in? I'm on the latest tagged version (0.4.1) and it is still occurring for me. |
0.4.1 should have fixed this, are you sure? Can you share some logs? |
It turns out to be unrelated, but if you don’t provide a database name at all, it throws an error, that was the mistake I made
…________________________________
From: Duologic ***@***.***>
Sent: Wednesday, April 13, 2022 7:17:36 PM
To: crossplane-contrib/provider-sql ***@***.***>
Cc: Alex Bowers ***@***.***>; Comment ***@***.***>
Subject: Re: [crossplane-contrib/provider-sql] Mysql provider crashes when creating user (Issue #74)
0.4.1 should have fixed this, are you sure? Can you share some logs?
—
Reply to this email directly, view it on GitHub<#74 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAGNZXU7HE7LGSY6BCOGCODVE4FUBANCNFSM5RFYSKHA>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What happened?
I receive a SIGSEGV when I try to create a Mysql user.
The
provider-sql-*
pod incrossplane-system
goes into CrashLoopBackOff cycle, which stops if I delete both user and providerconfig.My config is quite the same as multiple examples and I haven't found a similar issue anywhere, so I recognize that I may have just missed some small thing.
Note: I have a similar setup with postgres role, works correctly. Not sharing the example here to not pollute the issue, let me know if it helps.
How can we reproduce it?
DB cluster is AWS aurora-mysql.
I created a connection secret similar to the one in README:
Digression: I thought that the issue was with the secret created by Crossplane that missed
port
. With that secret the connection to the cluster would not succeed with the timeout:Editing that secret to include port 3306 causes the same behavior as described here for the generic secret.
(end digression)
Then I created a providerconfig:
And finally, a user:
What environment did it happen in?
Crossplane version: 1.6.1
provider-sql: 0.3.0
provider-aws: 0.23.0
Cloud provider: aws
Test done with mysql-aurora cluster, 1 writer: 8.0.mysql_aurora.3.01.0, instance db.r5.large
kubectl client: 1.21, server 1.20.
The text was updated successfully, but these errors were encountered: