-
Task
-
Resolution: Unresolved
-
Major
-
None
-
17.0.0.Final
-
None
Ultimately, we could employ WildFly Discovery SPI to handle services discovery in a generic way. However, since the subsystem currently only supplies one provider based on static discovery, its usefulness is limited. To untangle the chicken-egg problem, we could first integrate the clustering subsystems with the discovery SPI,
- JGroups discovery
- remote-cache-container remote servers
- mod_cluster
then supply discovery providers,
- static list (implemented)
- multicast-based
- k8s-based (replacing JGroups' OPENSHIFT_PING, DNS_PING, KUBE_PING, etc)
- cloud providers specific (replacing S3_PING, NATIVE_S3_PING, AZURE_PING, GOOGLE_PING, etc)
This requires fixes to the discovery subsystem such as
- ability to register new providers
- Adding/removing services from static providers should require server reload, or restart of the service providing the DiscoveryProvider
- TBD
- incorporates
-
WFLY-12220 Implement JGroups discovery protocol based on WildFly Discovery SPI
- Open
-
WFLY-12221 Integrate mod_cluster subsystem with WildFly Discovery SPI
- Open
-
WFLY-12223 Configuring remote-cache-container datagrid nodes based on WildFly Discovery SPI
- Open
- is blocked by
-
WFCORE-4535 WildFly discovery subsystem registers capabilities using an ambiguous contract
- Closed
- is documented by
-
WFLY-12225 Document missing discovery capabilities
- Closed