Closed shakeeb-upstart closed 1 month ago
That makes sense to me. Perhaps we could add a constructor to KubernetesApiServiceDiscovery
that you can provide your own org.apache.pekko.discovery.kubernetes.Settings
-like object to instead of relying on the one from the system
- would that work in your case?
Yeah that would work, I was only thinking of podNamespace
and overloading it to a separate method, but having Settings
will give us ability to configure the other options as well
Nice! Would you be up for the challenge of contributing this improvement?
Yes sure
I cannot make changes to the constructor, It has to abide by the ServiceDiscovery
constructor for 'DynamicAccess'.
would it be possible to have two constructors, one like the original for 'DynamicAccess' and one that takes a custom Settings
?
I tried with defining 'apply' method in the companion object but it doesn't work.
I think this will do, given the lookup is in the same Kubernetes cluster
I tried with defining 'apply' method in the companion object but it doesn't work.
Perhaps if you add this to the class instead of creating an apply method?
def this(system: ActorSystem) = {
this(Settings(system))(system)
}
Yup that worked
Hi, can we add a new helper method in the "KubernetesApiServiceDiscovery" class, to lookup services in a different namespace than the default provided in the configurations. I am trying to lookup a service that's in a different Kubernetes namespace.