Clojurians Log v2

Is there a reason why you can’t set host= the internal host name and alt-host= the external one?

When we do that I can connect from external network, but internally peers fail with errors like this:

Error communicating with HOST datomic.app.svc.cluster.local or ALT_HOST staging-app-transactor on PORT 4334

So what name should internal Peet’s use?

datomic.app.svc.cluster.local

staging-app-transactor is external

So the first one is what you want in a connection uri as an override?

Looks like it wouldn’t work even if you could?

See as its my dev env (REPL) client in external network that needs to connect to the transactor, I would like to specify the transactor's host name staging-app-transactor in the connection URI.

I can connect to it from host directly to that host on port 4334, but storage reports alt-host as the internal host name (`datomic.app.svc.cluster.local)`, which doesn't exist outside the k8s cluster

> See as its my dev env (REPL) client in external network that needs to connect to the transactor, I would like to specify the transactor's host name staging-app-transactor in the connection URI. I understand that. So I asked why you can't configure the transactor to host=datomic.app.svc.cluster.local and alt-host=staging-app-transactor, and you said because the peers (= internal clients) would get the error Error communicating with HOST datomic.app.svc.cluster.local or ALT_HOST staging-app-transactor on PORT 4334, which is the error peers would get if it could not use either of those host names.

can you confirm what ip datomic.app.svc.cluster.local resolves to on peers and the transactor itself?

Not easily. AFAIU that is set and shared between the pods by k8s itself

But we also know that the host name is correct, because when alt-host is set to it (and host to 0.0.0.0), then everything works on the internal network

Just for background: the transactor resolves host, and binds to the IP it resolves to, and writes both host and alt-host to storage. The peers read storage then try both host and alt-host.

if host=internal hostname and alt-host=external hostname, can external peers connect to the transactor?

Yes, but not internal ones.

so could datomic.app.svc.cluster.local resolve to a different ip address on a transactor pod vs another pod in the network?

perhaps one that internal traffic is not routed to?

I guess it's possible, but highly unlikely.

Fundamentally host= must be some value that resolves to an IP (not name) on the transactor that k8s will route traffic to from any source, internal or external.

OK, let me experiment a bit more and get back to you. Thanks for the assistance! gratitude

Fundamentally, though, this strikes me as a bit of an odd design decision for Datomic (to relay transactor hostname exclusively via storage). This is because there are a plethora of networking setups where the chosen solution could be problematic. OTOH the connecting client (my computer) has all the networking information it needs to connect to both the storage and the transactor, only this design choice means Datomic won't let me.

Transactors come and go, storage is forever

Consider also HA cases where there are multiple transactors, and you may not know which one is the active one.

That certainly makes sense, but something like HA could be a counterpoint too: the client may have better information about which transactor is more appropriate for it, given its network setup. Having the current behavior is fine as a default, but I'd really expect to be able to override it.

I think host= represents an expectation that hostnames should be stably-resolvable (especially in the one-network environment peers+transactors should run in). alt-host= is already a concession to the reality that network topologies are bonkers

fwiw I only ever encounter hostname problems like this with k8s networking, which I think says more about k8s networking than datomic

> network topologies are bonkers This is the big thing at play, yes 😅

> which transactor is more appropriate for it, given its network setup. To be clear, there's only one active transcator, and peers don't get to choose.

HA is a hot-spare/failover situation

> fwiw I only ever encounter hostname problems like this with k8s networking, which I think says more about k8s networking than datomic Respectfully, I disagree. k8s may be a common scenario for this to crop up in, but I can easily contrive others. But regardless, it is really Datomic that's the odd one out here, in a sea of other servers that don't prescribe network level details like this. And I would bet that many of them avoid solutions like Datomic's precisely because "network topologies are bonkers". The point I'm trying to make: Datomic should not care about the network its topology.