Open whutwhu opened 1 month ago
CC @adisuissa I am not sure I fully understand what multiple upstream endpoints mean. I thought ODCDS/VHDS operate on downstream requests, not upstream endpoints.
Hi @kyessenov This includes an explanation of downstream
and upstream
in the context of Envoy:
https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/intro/terminology
Regarding "multiple upstream endpoints," we can only subscribe to the full resource from one service. However, if multiple services need to be accessed, only the first one works without any issues.
@kyessenov @adisuissa Could you provide any guidance or share concerns and suggestions? If there are no issues, I’ll go ahead and submit a PR for your review. Let me know if anything comes up.
I've opened a PR: https://github.com/envoyproxy/envoy/pull/36527
The first request from an upstream endpoint triggers our on-demand xDS flow (
VHDS → CDS → EDS
), subscribing to the necessary resources. However, when multiple upstream endpoints are involved, only the first one functions correctly. For subsequent endpoints, EDS is not initiated, blocking the retrieval of the clusterLoadAssignment resource for those clusters.The issue arises in
OdCdsApiImpl::updateOnDemand
:StartStatus::NotStarted
.NewGrpcMuxImpl::addWatch
is called, adding the cluster to the watch and subscription interest lists.StartStatus::InitialFetchDone
.GrpcSubscriptionImpl::requestOnDemandUpdate
is triggered with StartStatus::InitialFetchDone, but it only updates the subscription interest list and doesn't update the watch interest list.Instead of calling
GrpcSubscriptionImpl::requestOnDemandUpdate
after the first CDS request,GrpcSubscriptionImpl::updateResourceInterest
should be called to ensureNewGrpcMuxImpl::addWatch
updates the watch interest list and triggers the EDS flow.I would appreciate feedback from the community. We are currently using Envoy version 1.25.7, but it appears this issue may also persist in the most recent code.