[mysql-remote] Add proxy service for remote mysql

[themightychris]

See original discussion on forum: https://forums.habitat.sh/t/binding-to-remote-services/531/2

I'm not sure if it's appropriate to merge a plan like this into core but want to at least kick off a broader discussion.

This package exposes a service that can take the place of core/mysql in a bind, but which is configured with full connection details to an external mysql instance. It runs a dummy sleep service and provides a client.cnf similar to core/mysql's that is used for a connection health check

[thesentinels]

Thanks for the pull request! Here is what will happen next:

1. Your PR will be reviewed by the maintainers
2. If everything looks good, one of them will approve it, and your PR will be merged.

Thank you for contributing!

[predominant]

I'm a huge fan of this approach. We use it to achieve legacy connection, and combine with Consul to provide bidirectional service binding for application migration.

Example: https://github.com/predominant/habitat-bind-service

While I love this pattern, I don't think this belongs in core plans. We should educate users on how to achieve this service proxy pattern. I think a blog post and some addition to documentation would be ideal.

[themightychris]

@predominant your pattern is a bit different in that you're crafting a particular mix of services together into one bind service. I see a lot of value in that pattern for simplifying composite services but agree that the choosing of a mix of services makes it a bit too use-case-specific for core plans

I'd suggest what I'm proposing is a bit different though, in that this mysql-remote plan aims to strictly replicate the pkg_exports and health_check of the mysql plan. In aiming to be a remote variant with drop-in compatibility with core/mysql, there's no room for its scope to expand in use-case-specific ways and everyone who wants to drop a remote connection into a bind meant for core/mysql is going to end up writing pretty much exactly the same plan.

Also, if the pkg_exports or health_check for core/mysql evolves, it would be desirable for core/mysql-remote to evolve in a synchronized way. Having a core plan makes it more likely that everyone will get to benefit from robust health checks like core/mysql comes with.

[predominant]

Yep, I see where you're coming from. I still think that this "pattern" is very useful, and is how I am able to easily migrate to habitat from legacy systems.

I think this implementation can be left to the user, however. Otherwise we open up the possibility of having *-remote plans littering the core plans.

[rsertelon]

This is really awesome, and could even help with non legacy software using AWS RDS for example.

However, I feel too that this might add a lot of package, and we'd have to maintain compatibility "by hand", meaning that habitat can't help us spot this easily.

But the healthcheck and other small things might be worth centralizing in core... Hard to tell, this is most likely an RFC subject IMHO.

[nellshamrell]

@themightychris - could you please add in a README and correct the Travis failures?

[themightychris]

@nellshamrell All set!

Any thoughts on naming? Would mysql-proxy, mysql-connection, or mysql-external be better?

[nellshamrell]

@themightychris - TY! Looks like we've got one merge conflict, could you correct that when you have a moment?

Otherwise this looks good! And I'm fine with using mysql-remote as the name.

[nellshamrell]

Closing this for now, pending discussion or adoption of habitat-sh/habitat#5262

This is good stuff, @themightychris - would you perhaps be willing to consider putting this on a different origin than core, so that it is available for people to use, while we are discussing the best way to do this in core plans.

[themightychris]

It's already available under jarvus/mysql-remote