search

petoju / terraform-provider-mysql

Terraform MySQL provider – unofficial fork
https://registry.terraform.io/providers/petoju/mysql
Mozilla Public License 2.0
65 stars 42 forks source link

Native support for Cloud instances #40

Closed tun0 closed 2 months ago

tun0 commented 1 year ago

In order to properly provision MySQL instances within (in our case) GCP, it would be nice if this provider would use (for example) Go CDK to connect to Cloud instances.

petoju commented 1 year ago

@tun0 I have already considered it, but it's not really testable.

Or do you have any idea, how to test it works correctly from any dev? Currently, we're using Docker and that works for local connections. We don't have any solution for clouds.

tun0 commented 1 year ago

@petoju Perhaps its PSQL sibling can be used as an example?

https://github.com/cyrilgdn/terraform-provider-postgresql

That one is working pretty well for our PSQL instances.

I haven't looked into either in very much detail to see how much could be "borrowed".

petoju commented 1 year ago

@tun0 the issue is not in how to implement it once.

The issue is in how to avoid breaking it. That's why I'm adding new tests with new issues. It's really easy to refactor something and forget about an edge condition.

I don't see any relevant tests of cloud part in that repo - but feel free to point me to some.

tun0 commented 1 year ago

@petoju Perhaps AWS/GCP/etc free tiers could be used for testing? I kinda hoped the PSQL provider would have more extensive testing. But looking at it now, it seems very simplistic indeed.

petoju commented 1 year ago

@tun0 don't they have any docker image that does it? Getting a free tier is easy; providing it to GitHub and so on without risk of going over the quota is a bit more complicated.

tun0 commented 1 year ago

@petoju The situation appears to be even worse: Cloud SQL isn't covered by GCP's free tier at all. Nor does there seem to be an emulator for it (which doesn't really surprise me given all the complexity involved). So, testing this properly in an automated way is gonna be really hard (and/or expensive) :disappointed: Which pretty much leaves us with an (mostly) untested approach, either alongside the current implementation (using different configuration directives) or even in some fork for example. I'd prefer the former, but can imagine that from a maintainer point-of-view it wouldn't be very desirable.

tun0 commented 1 year ago

On the other hand, fully automated testing would involve not just GCP, but also AWS, Azure and possibly more down the road. That'd make it even harder to achieve. Did browse a bit through the Go CDK tests as well. But couldn't make much sense of that either (regarding functional testing that is).

petoju commented 2 months ago

I merged some changes even without testing... I rely just on user reports to know, whether everything works.

So it's worse than ideal, but users have the features.