[jboss-jira] [JBoss JIRA] (WFLY-12222) Clustering subsystems integration with WildFly Discovery SPI (tracker Jira)

Radoslav Husar (Jira) issues at jboss.org
Fri Jun 21 05:06:00 EDT 2019


     [ https://issues.jboss.org/browse/WFLY-12222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar 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
* 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
# etc




> Clustering subsystems integration with WildFly Discovery SPI (tracker Jira)
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-12222
>                 URL: https://issues.jboss.org/browse/WFLY-12222
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering, mod_cluster
>    Affects Versions: 17.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Major
>
> 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)


More information about the jboss-jira mailing list