Restore multicast-discovery

[macdjord]

We have an elasticsearch cluster using containerized nodes; our method of Docker deployment makes assigning fixed IP addresses non-trivial, so we depend on multicast discovery to allow our nodes to connect. We were therefore very surprised when 5.0 came out and multicast support had been removed; we had been under the impression that the deprecation warning meant that the multicast-discovery core module was being deprecated in favour of the multicast-discovery plugin - not that muticast support was being dropped entirely. (And, indeed, we duly installed and deployed the multicast-discovery plugin some time time ago, and it worked just fine.)

Please restore multicast support; this is blocking our upgrade to 5.0.

[jasontedor]

We are not going to restore this, we outlined the reasons for removal of multicast from core in Elasticsearch unplugged - Networking changes in 2.0 and removal as a plugin in #16310.

Can you use hostnames and DNS resolution? There are some options here. Please consider opening a topic on the Elastic Discourse forum.

[macdjord]

All the listed reasons for removing multicast - issues with localhost, issues with OSX, not available on some networks - look, to me, like excellent reasons for not using it as the default, since not everyone is in a position to use it. But none of them apply to us: we're not binding to localhost, we're not on OSX, and our network does support it. Why should support not be available for those who can use it?

Last time we tried using DNS for this, we found that, if you had a hostname in the unicast discovery list, the node would attempt to resolve it during startup - and die if it failed. And if it succeeded, it cached the resulting IP permanently, so it would never pick up any changes in IP.

[jasontedor]

Why should support not be available for those who can use it?

We have finite engineering resources, the download numbers of the multicast plugin do not justify exerting those engineering resources on it.

Last time we tried using DNS for this, we found that, if you had a hostname in the unicast discovery list, the node would attempt to resolve it during startup - and die if it failed. And if it succeeded, it cached the resulting IP permanently, so it would never pick up any changes in IP.

This is what I was expecting, and like I said, there are options here. The issue that you're referring to is #14441. A fix is coming very soon. You can also consider using the discovery-file plugin for now, which will re-resolve when needed.

[jasontedor]

Last time we tried using DNS for this, we found that, if you had a hostname in the unicast discovery list, the node would attempt to resolve it during startup - and die if it failed. And if it succeeded, it cached the resulting IP permanently, so it would never pick up any changes in IP.

@macdjord Both of these issues are fixed in the forthcoming 5.1.0 (no date, sorry). See #21630 for details, and the two linked issues from there. For the JVM DNS cache, you will have to adjust the system security policy. This is covered in the expanded Zen discovery docs.