bitflicker64 commented on PR #3132:
URL: https://github.com/apache/hugegraph/pull/3132#issuecomment-5504086599

   Pushed one more commit: Servers now announce their own Pod IP to PD instead 
of the shared client Service URL, porting c2d086de from helm-dev. This is the 
last behavioural difference between the two branches, so flagging the reasoning 
here rather than merging it silently.
   
   Why Pod IP rather than the Service URL: the PD registration in 
`GraphManager.registerServiceToPd` is a lease. Each URL becomes a 
`DiscoveryClient` that re-registers on a schedule, and a replaced Pod's entry 
ages out when its heartbeat stops. With the Service URL, all three replicas 
derive the same client id and collapse into one entry that they take turns 
renewing, so PD reports one Server and the per-instance labels (such as 
`cores`) are meaningless. With the Pod IP the registry stays truthful, which is 
what the Hubble cluster view from #3159 is there to show. The cost is a short 
window during a rollout where a discovery client can be handed an entry that 
has not yet expired; application traffic is unaffected since it goes through 
the Service either way.
   
   `server.advertiseUrl` keeps its meaning: set it and every replica announces 
that shared endpoint, for an outside Hubble. `POD_IP` is added to the reserved 
env names. Four unit tests cover the fieldRef, the default URL shape, the 
override and the reserved name; 44 tests pass.
   
   The stale window is bounded by the discovery lease interval on the PD side; 
I will size it and add a line to the Limitations section. Both variants have 
passed the full scenario battery, so this is a design choice on my side: the 
truthful replica list is what the Hubble cluster view is built to show, and the 
lease already handles cleanup.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to