Closed Slideee closed 1 year ago
@Slideee IMO it's quite a good idea, could you provide your design with more details? My advice:
HttpDomainSite
should be kept simple. And the current way to support updating nameserver addresses is as follows:
In RocketMQ 4.9.4 LTS or 5.x, there's a scheduled task to check and update nameserver addresses from BrokerConfig
, which is updated by nameservice_controller
if the addresses of nameserver pod are changed.
@Slideee IMO it's quite a good idea, could you provide your design with more details? My advice:
HttpDomainSite
should be kept simple.- Users can also provide their own domain site service, in that case, the user-predefined one should be preffered.
And the current way to support updating nameserver addresses is as follows: In RocketMQ 4.9.4 LTS or 5.x, there's a scheduled task to check and update nameserver addresses from
BrokerConfig
, which is updated bynameservice_controller
if the addresses of nameserver pod are changed.
I checked the code of version 4.9.4 and found that there is indeed a new scheduled task to update NamesrvAddr.
For HttpDomainSite
resource, current thinking is as follows:
Nginx
base image.ReadinessProbe
under the container. and then NamesrvAddr will exist in the directory inside the pod.HttpDomainSite
headless service domain name and sub path to the Broker environment variable ROCKETMQ_NAMESRV_DOMAIN
and ROCKETMQ_NAMESRV_DOMAIN_SUBGROUP
.However, it is now supported to dynamically update the NamesrvAddr, and it is not clear when the HttpDomainSite
service is necessary.
@Slideee In current implementation, the complexity will increase as the number of broker clusters increases, because name service controller should update the namesrvAddr
of EVERY broker properly. Furthermore, if all name servers restart and all of their IPs change, there's no way for broker to register to new name servers.
So I think it's worth supporting fetching namesrvAddr
from ROCKETMQ_NAMESRV_DOMAIN
.
For your design, IMO it's unnecessary to add a new CR, just let name service controller to maintain this service.
According to the logic of the current RocketMQ kernel, if the Broker needs to dynamically perceive the change of NamesrvAddr, it can only be done through the HTTP domain site service. By injecting the two environment variables
ROCKETMQ_NAMESRV_DOMAIN
andROCKETMQ_NAMESRV_DOMAIN_SUBGROUP
, the Broker can dynamically perceive the NamesrvAddr.So I plan to add a
HttpDomainSite
resource to the Operator as a site service to dynamically sense the changes of NamesrvAddr, and create a headless service, which is injected into theROCKETMQ_NAMESRV_DOMAIN
as the domain. this avoids instability from Broker rolling rebuilds.If the community thinks this solution is feasible, I will submit relevant PR in the near future.