Why do you want this option? The intent of the option was a hack to ensure that the gateway is not marked ready prematurely which we have fixed in other ways
I want this option for the same purpose, not to mark the custom user gateway ready prematurely.
Could you inform how is it fixed in other ways?
@howardjohn
We check Envoy’s internal readiness state, which will not be marked ready until it has fully loaded all config sent to it
do you mean in 1.5 alpha “15020/healthz/ready” readiness probe is changed?
what i observed is that envoy gets added into k8 service before it receives the listener config from pilot, client gets connection refused for ~1 second when envoy doesn’t have listener ready.
after adding --applicationPorts option (via helm’s applicationPorts variable) to pilot agent, envoy becomes ready only when it has all the listeners mentioned in applicationPorts are ready.
I verified this by using some non configured listener port, then envoy pod wasn’t ready because readiness probe 15020/healthz/ready was giving 503.
thats why this option is useful unless there is some other method implemented to achieve the same in 1.5 alpha.
what i observed is that envoy gets added into k8 service before it receives the listener config from pilot, client gets connection refused for ~1 second when envoy doesn’t have listener ready.
If that is true its a bug. We explicitly check that envoy has received listener config before we mark it as ready.