Broker supports dynamic update of the nameservice address

[Slideee]

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 and ROCKETMQ_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 the ROCKETMQ_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.

[caigy]

@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 by nameservice_controller if the addresses of nameserver pod are changed.

[Slideee]

@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 by nameservice_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:

1. It is based on Nginx base image.
2. When the Operator is Reconciled, pod and headless service are created.
3. Run a script to update NamesrvAddr regularly through ReadinessProbe under the container. and then NamesrvAddr will exist in the directory inside the pod.
4. Set the 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.

[caigy]

@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.