Return the health server when setting up

[GTB3NW]

Allows for a DRY approach to setting up a re-usable health server. My use case is that I want to serve some services as healthy when they're read-only, therefore allowing a single connection to be used for multiple clients. If you think I should take a different approach feel free to correct me :)

[Jille]

Hi Ben!

Thanks for your PR. I don't think I understand what you're trying to achieve yet. Are you trying to avoid having to import google.golang.org/grpc/health/grpc_health_v1 in your calling code? That seems reasonable.

So far my idea for the Setup() function is that it's a convenience wrapper, and people wanting to do more difficult things can use Report() directly. If we're going to return *health.Server from Setup(), we should probably document that most callers should ignore it.

[GTB3NW]

Hi Ben!

Hello!

Thanks for your PR. I don't think I understand what you're trying to achieve yet. Are you trying to avoid having to import google.golang.org/grpc/health/grpc_health_v1 in your calling code? That seems reasonable.

No worries, thank you for open sourcing! Sorry I explained badly. No we're not trying to avoid the import of that package, I'll address the change in the next quote. As for what we're trying to achieve...

So we want all writes to only go to the raft leader, which you package currently achieves very nicely. We'd also like to send all reads to followers, thereby offloading the burden from the leader. Exposing the health pointer allows us to piggy back of the existing health and add some additional services which we don't want the leaderhealth package to control the health for (the followers). If we reuse the health pointer, it means we can put all services on a single port, albeit we would need separate read/write connections on the clientside. To clarify, the services are split into read/write, only RPC's which write data will be in the write services and there will be a sister read service for anything which reads.

So far my idea for the Setup() function is that it's a convenience wrapper, and people wanting to do more difficult things can use Report() directly. If we're going to return *health.Server from Setup(), we should probably document that most callers should ignore it.

That's currently what I'm doing, I've replicated the setup function. The only thing the setup function wasn't doing which I needed was returning the pointer so I could add additional services. Sure the PR will break the signature and might require a slight version bump but I personally think it's worth it for re-usability. Hopefully that makes sense?