These are chat archives for atomix/atomix

4th
Oct 2018
Jordan Halterman
@kuujo
Oct 04 2018 01:02

Helm charts are now available for running Atomix on Kubernetes!

https://atomix.io/docs/latest/user-manual/deployment/kubernetes/

The documentation sucks, but that’s pretty much all I’m working on this week so it will improve

also, there’s now a terrible downloads page on the website
no one ever claimed I was a web designer 😉
Luca Burgazzoli
@lburgazzoli
Oct 04 2018 07:27
ok so it is not a true dns discovery where members are dynamically found using dns+srv
@kuujo is dns+srv something you are interested in ? if yes I can contribute an implementation
Jordan Halterman
@kuujo
Oct 04 2018 09:01
Yes! Kubernetes DNS does create SRV records as well, and we can use them and drop the ports as well.
I’m just not sure how it will look in the current API. Maybe just a null address and use the MemberId to lookup the host/port?
this is what I did so far
Jordan Halterman
@kuujo
Oct 04 2018 09:03
Have to think about how that would work
Luca Burgazzoli
@lburgazzoli
Oct 04 2018 09:04
so the id of a member is retrieved from the pod name, which for a stateful set, is stable
when you configure discovery, the things you have to provide are related to the srv entry
of course each node need to set its own id from the node name
Jordan Halterman
@kuujo
Oct 04 2018 09:18

I think it can be made to do a SRV lookup when you do e.g.:

NodeDiscoveryProvider provider = BootstrapDiscoveryProvider.builder()
  .withNodes(“foo”, “bar”, “baz”)
  .build();

I probably have to take a look at this in the morning because the low Address class and low level messaging APIs aren’t really designed not to have a host:port tuple ATM. We probably have to modify the MessagingService to do SRV lookups

Luca Burgazzoli
@lburgazzoli
Oct 04 2018 09:20
they will have it
the local address of a node is retrieved from the node
then the discovery creates addresses with host:port
but I may be missing something
Jordan Halterman
@kuujo
Oct 04 2018 21:27
Actually, I think I have a better idea
Jordan Halterman
@kuujo
Oct 04 2018 22:02
I think you have the right idea, but the way NodeDiscoveryProviders are used needs to be changed a little bit
this has been needed for a while… might as well do it today