[ https://issues.jboss.org/browse/WFLY-12222?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-12222: -------------------------------- Description: 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 * changing static providers should require server reload, or restart of the service providing the DiscoveryProvider * TBD was: 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 * changing static providers should require server reload * TBD -- This message was sent by Atlassian Jira (v7.12.1#712002)