Support tailnet for `cb uri`, `cb psql`

[nickstenning]

One quality of life improvement I'd greatly appreciate is if cb uri and cb psql were able to (respectively) return a database URI for access over the tailnet, or connect directly over the tailnet.

I don't know how easy it is to get that information, or whether it would be possible to expose the tailnet addresses at -- for example -- t.<clusterid>.db.postgresbridge.com, but at the moment we have a bunch of scripts that sed the output of cb uri and it would be lovely to not have to do that.

[abrightwell]

Hey @nickstenning I've shared this with the team for discussion. Thanks for the feedback.

[nickstenning]

Hey Adam! I'm curious to know if this is something you've discussed further? It's still something that I think of a few times a week.

[abrightwell]

Hey Nick. Yes, it's been/being discussed, but I've not had a chance to followup with it here just yet. It's definitely on the radar though.

I started digging into a little bit and have a lot of notes on how we can potentially handle this as it requires directly communicating with the local Tailscale client service (tailscaled). And I've discussed/shared those notes on how we can best approach this with other engineers.

But this presents an interesting question, should cb interface with the local tailscaled or should the backend do that on the cluster side and then provide it to cb via the Bridge API. I think that's the initial engineering hold-up at this point, but I believe we're all leaning towards the latter.

Regardless, my understanding is that we might be able to provide a temporary solution to override the connection URL that cb uses by allow a client to use what they see in their tailscale client. For instance, usually just the hostname of the device to connect to is needed if connected to the tailnet, as the client should obviously handle all the DNS lookup, etc.

That's obviously not the best UX, especially if it required you changing up how you use the CLI twice. But it might be an interim solution to help your workflow while we work on a more appropriate option/flow for it.

In my view, the less calls cb has to make to such locally running services, the better (preferably it would be zero, IMV). Also, I would much prefer it to be something available in the API such that other consumers can utilize it as well. But I digress...

I know this doesn't answer or resolve your question/issue at this time. But it's not going ignored and will hopefully be addressed sooner than later.

[nickstenning]

should cb interface with the local tailscaled or should the backend do that on the cluster side and then provide it to cb via the Bridge API

I don't think my opinion here is worth much, not knowing the details of your infrastructure, but I had certainly been assuming it would be the latter, too.

For instance, usually just the hostname of the device to connect to is needed if connected to the tailnet, as the client should obviously handle all the DNS lookup, etc.

Right. That is effectively what I've been doing locally, with the rather awkward cb uri <clustername> | sed -E 's|@p.([^.]+)[^/]+|@\1|'.

Thanks for continuing to think about it :)

[abrightwell]

@nickstenning, I was thinking a little more about it this morning, I'm curious, would something like the following work for you?

cb uri <cluster> --tailscale
cb psql <cluster> --tailscale

The thought being that I could at least abstract away the need to do the sed you mention above. And if/when we do reach a solution on the API side, it would be without consequence to your work flow and potentially others.

If that seems like it would work for you, then I'll run it by some others internally to ensure it will work for their use cases as well.

Thoughts?

[nickstenning]

That was pretty much exactly what I was thinking, so it would definitely work for me!

[abrightwell]

Sounds good. I'll see if I can expedite this one for you and get out a release sooner than later. 👍