Igor, actually you are right. We already have org.apache.ignite.ips node attribute, which contains all the IPs. No need to add anything else, just filter the value according to IgniteConfiguration.LocalHost. I'll update the IEP and POC.
Thanks On Mon, Apr 27, 2020 at 8:17 PM Pavel Tupitsyn <ptupit...@apache.org> wrote: > > There is already a list of addresses of every node kept by every node, > isn't it? > > Can you please elaborate, what exactly do you mean here? > Sure, we can get addresses of other nodes from Discovery/Communication > SPIs, > but those addresses may be not what we want. Nodes can belong to multiple > subnets. > > For example, server nodes may communicate over 192.168.0.0/24, but expose > client endpoints over 10.0.0.0/24 as well. > > We have to conform with IgniteConfiguration.LocalHost setting. > If it is not set, or set to 0.0.0.0, we should gather IPs from all > interfaces. > But if it is set to something, we should gather only matching IPs. > > On Mon, Apr 27, 2020 at 5:43 PM Igor Sapego <isap...@apache.org> wrote: > >> Great, this feature is long awaited. >> >> 1. I believe so. Since I've proposed Partition Awareness feature I was >> thinking >> about a way for clients to discover cluster nodes. >> >> 2. In my opinion a simple boolean flag is enough for the beginning. In >> future >> maybe we can add a node filter. This can be useful in cases when part of a >> cluster is not available from client network or if user wants to avoid >> connection >> to a node for some other reason. >> >> 3. There is already a list of addresses of every node kept by every node, >> isn't it? >> >> Best Regards, >> Igor >> >> >> On Mon, Apr 27, 2020 at 12:58 PM Pavel Tupitsyn <ptupit...@apache.org> >> wrote: >> >> > Igniters, >> > >> > I've prepared an IEP [1] and a POC [2] for Thin Client Discovery >> feature. >> > Let's discuss it here. >> > >> > In particular, I'd like to address the following points: >> > >> > 1. Value: do you think this would be a good feature to have? >> > 2. Public API changes: is a boolean property enough? Should we have >> > something more complex, so users can plug in custom logic to filter >> and/or >> > translate IPs and host names? >> > 3. Server-side implementation details: should we use Compute, Node >> > Attributes, or something else to retrieve client endpoints from all >> nodes >> > in cluster? >> > >> > [1] >> > >> > >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-44%3A+Thin+client+cluster+discovery >> > [2] https://github.com/apache/ignite/pull/7744 >> > [3] https://issues.apache.org/jira/browse/IGNITE-12932 >> > >> >
